Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

Hi all,

-1 for going back to annual releases.

For stable components there is an option to keep the same version contributed for a number of releases - this should be sufficient to support "annual release" experience.
For new and incubation components "annual" may mean mostly "next life".

For people that wants to contribute a patch it sounds like "ok, if you will be patient enough to go through all the environment setup, reviews and discussion - you have a chance to see you change next year" - for a majority of newcomers this doesn't look attractive.
For eclipse-based vendors - annual release is the invitation to do a fork and think about switching to another platform. Why? Because "another platform" with growing popularity has monthly releases.

Also annual releases will resurrect a number of "service releases" with all the effort required, at least to support the new Java versions. So, as Mickael stated below, the effort is comparable.

I agree with Mickael that only enforced automated reject via pipeline rules can improve the situation with release quality. Passing pipeline should mean "the change is good enough to spent time on final review before the merge".


29.01.2020 12:58, Mickael Istria пишет:

On Wed, Jan 29, 2020 at 10:46 AM Matthias Wienand <matthias.wienand@xxxxxxxxx> wrote:
Hi all,

+1 for going back to annual releases.

Projects are not forced to do quarterly releases. You can have your project do a yearly release, but it just means that since Platform releases every 3 months, you need to check your project against 2 milestones and 2 RCs of the Platform every 3 months (12 times a year). Which doesn't change much compared to previous state where projects were supposed to be tested against all Platform milestones and RC, ie 11 times a year.\

The work done by Ed M is very appreciated. Ideally, the different checks (e.g. licenses) could be automated to prevent degradation of SimRel quality.

Some checks have already been possible to automate for a while:
The licence check may be missing, and could be added.
Or one can probably just build a similar Maven configuration to run the other analyzers.
But the real thing is that what matters is not building the report, but enforcing rules without human intervention. This typically happens only with mechanism that fail the build in case the analyzers see issue. As long as human reading is required, it cost too much effort and time to someone, and feedback loop becomes too long. The only good way to report a bad state is to fail the build so it doesn't pass review.

cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top