Hi
That makes sense but shows that we are just shifting the problem.
I see a requirement for
- regular base releases (yearly)
- maintenance releases (four monthly)
- responsive releases (four monthly)
Recognising that maintenance releases were being abused to provide
responsive releases is probably good, but waving goodbye to maintenance
releases is bad.
IMHO we need all three and so long as we try to make do with two we will
be in trouble with some user community. It seems wrong that because some
projects have abused the principles of maintenance, users of other
projects that have observed maintenance discipline suffer.
Regards
Ed Willink
On 24/09/2015 15:35, Ian Bull wrote:
Ed,
The reason for the change from Mars SR1 to Mars 1 is because this is
how we've been doing it for years. Many people (EGit / JGit, Mylyn,
CDT -- to name a few) had been putting minor releases in the release
train during the SRs. I ran some numbers last year, and > 1000
Installable Units had incremented their minor version number between
SR0 and SR2. This means, assuming people are following the version
guidelines, that up to 1,000 bundles had already been adding new API
between SR0 and SR2.
Changing the name of the train just means we are acknowledging what
was already happening.
Cheers,
Ian
On Wed, Sep 23, 2015 at 11:21 PM, Ed Willink <[email protected]
<mailto:[email protected]>> wrote:
HI
Surely this is the inevitable consequence of Mars.1 rather than
Mars SR1?
SR1 required each component to be a safe upgrade so that exact
release timing was irrelevant.
Mars.1 is a new release so users must get to see the co-ordinated
new release in one go rather than incrementally. If A.1 pulls in
B.1, but C uses B, users of C are in a mess until they get C.1.
Regards
Ed Willink
On 24/09/2015 05:26, Gunnar Wagenknecht wrote:
David,
Am 23.09.2015 um 23:37 schrieb David M Williams
<[email protected]
<mailto:[email protected]>>:
If not obvious, this means all participants in
"coordinated release train" should not make your releases
visible on 9/25, but wait until 10/2 10 AM to make them
visible, and announce your official releases.
This seem unnecessarily restrictive. I don't bother with the
announcement part. However, I don't recall there is something
in the process that requires project to wait publishing the
release bits. Not making them visible could have a huge effect
on a project's adopter community.
-Gunnar
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
<mailto:[email protected]>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2015.0.6140 / Virus Database: 4419/10692 - Release Date: 09/24/15
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
