Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strategy for handling dependencies to system releases #304

Open
ConjuringCoffee opened this issue Mar 7, 2023 · 4 comments
Open

Strategy for handling dependencies to system releases #304

ConjuringCoffee opened this issue Mar 7, 2023 · 4 comments

Comments

@ConjuringCoffee
Copy link
Contributor

ConjuringCoffee commented Mar 7, 2023

We started this discussion in pull request #303. Can we define an approach on how to handle Clean ABAP for different system releases?

Right now, we mostly formulate each rule how it applies to the newest system release. This can become complicated, especially when the rules are different for various system releases. In the example of !303, the recommended data type for versions starting with 750 is abap_boolean, whileit was xfeld previously. Another example is the usuage of ENUM. While constant classes are recommended for older releases, ENUM is the preferred option for newer releases.

My suggestion is the following approach:

  • Clean ABAP should always contain the ruleset for the latest system release.
  • I'd like to define a threshold system release, for example 7.50 or 7.40. If a section can only be applied to a release after the threshold release, then the section states this specifically (e.g. This section only applies to system release 7.50 or higher.).
  • If a section is only valid for system releases other than the newest system release, then it is moved to a separate file (e.g. CleanABAP_deprecatedRules.md). The rule should state from which to which release it is applicable to (e.g. This section is only applicable to releases up to 7.51.).
  • If a rule from the main document contradicts a rule from an older release (from the side document), then it mentions this (e.g. This rule only applies to system release 7.50 or higher. For earlier releases, please refer to rule XYZ).
@ConjuringCoffee
Copy link
Contributor Author

A few words regarding the motivation:

  • If you are on an older system release, you currently have no indication if a section is applicable to your system. Trial and error is sometimes required to know if you can even do what is being proposed.
  • Some rules are just lost to time, like with the xfeld recommendation from Update Booleans - use abap_boolean #303.

@Jelena-P
Copy link

There isn't a simple and perfect solution, unfortunately. We ran into this when writing the ABAP Intro book. At the time it was written, many companies still used pre-7.4 ABAP (and quite a few still do probably), so we ended up providing two code examples, when it was applicable: one for 7.4+, with inline declarations and all, and one for earlier versions.

I think it's fine to handle the version-dependent rules just like that. Simply state version X onward you do this, lower version do that. While I do agree that in general, the rules should reflect the latest version, realistically it's not the version available for many ABAPers and you still need to know what to do before that.

Also agree on "minimum version" and I think it should be 7.4. Maybe this should be handled like a person's resume (aka CV): at some point, you update it to add newer stuff and at the same time remove/shorten old stuff. FIFO :)

@gbrfarkas
Copy link

My team has run into this issue before as well while trying to adopt the clean ABAP rules.

I feel like that having a separate file for deprecated rules is a bit of an overkill though, I'd prefer if a rule went into detail about what should be done in releases older than the current one (but only down to the minimum release, which is a good idea, and I agree that it should be 7.4 as well).

@pokrakam
Copy link
Contributor

pokrakam commented Mar 14, 2024

I don't think this is a big issue, there aren't that many rules that are only possible on a super modern version, and having a deprecated style guide is a nice idea but disproportionate maintenance effort IMHO. Developers working on older systems should be aware of newer syntaxes and features and it should not be misleading to encounter a rule that is not possible on their version.
It's not that big a deal to make a note of any significant deviations either. For example when I couldn't apply Prefer RAISE EXCEPTION NEW to RAISE EXCEPTION TYPE, it took me a couple of minutes to find it in the ABAP release notes and raise a PR to add version info to the Style Guides, job done.
Maybe we could agree on a documentation standard, perhaps to add version info into the title if relevant?
Prefer RAISE EXCEPTION NEW to RAISE EXCEPTION TYPE (7.52 up)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants