[
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
|
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
пишет:
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.
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@xxxxxxxxxxx
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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev