Of course how often to release and in which form is also a digression...
I am kind of ambivalent on this topic. I do believe that quality has
suffered as a result of this new approach. As Sebastian mentioned, as a
consumer I now often have the choice between the old version with known
bugs versus the new version with unknown bugs. Neither is a great
choice. I don't think anyone is on safe ground arguing that quality has
actually been improved by eliminating service releases.
But I wonder the general feeling others are expressing that to them it
feels like the cost personally and for their projects is higher without
maintenance release. My sense is somewhat different. In the past I had
to maintain two streams and hence two development environments with two
different target platforms. I'd fix problems in master and then I had
to cherry pick them into the maintenance branch (with different version
increments). I also had to do builds for both streams. This duality
was more work than is currently the case maintaining only a single stream.
So I try to understand why there is the perception that maintaining one
stream is more work than maintaining two streams. I imagine part of the
problem here the extent to which changes in upstream dependencies are
disruptive to my project, which is more likely in a non-service stream.
I.e., did the Platform or EMF change something that makes Xtext no
longer work such that Xtext is forced to spin a new release rather than
feeding their existing release (or a maintenance release if they so
choose) into the train for the next cycle? The extent to which we all
avoid truly disruptive changes, surely it ought to be be less work in
general to release from a single stream...
Please correct any misperception I may have or illuminate any issues I
do not fully understand in this regard. I'd like to better understand
the perception of others. Please note that I agree that quality has
suffered, but that's a separate issue from the perception that it's more
work.
Regards,
Ed
On 29.01.2020 11:13, Alexander Fedorov wrote:
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".
Regards,
AF
29.01.2020 12:58, Mickael Istria пишет:
On Wed, Jan 29, 2020 at 10:46 AM Matthias Wienand
<matthias.wien...@itemis.de <mailto:matthias.wien...@itemis.de>> 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:
https://wiki.eclipse.org/CBI/p2repoAnalyzers/Repo_Reports#With_Maven
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
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
