Hi
That makes sense, one day, but today I am amazed that Check for Updates
does not offer me the fix for a bad NPE that EGIT fixed within days of Mars.
However it will still be helpful to get an SR1 EPP rather than upgrade
from SR0. The SR1 EPP could just be the aggregation on a given date
rather than the full RC* run-down.
Regards
Ed Willink
On 24/09/2015 19:09, Doug Schaefer wrote:
No, maintenance releases are still necessary. But you have to ask yourself, why
are we synchronizing them.
I think on another thread here we have the solution. Projects need to be free
to release maintenance releases at any time. We have the technology to make
Check for Updates work to find them. It's probably a bad idea to synchronize
them. Why wait for others if you have an update ready to go?
The main concern we've had is whether we can scale to have Check for Updates
check p2 repos for every project whose features you have installed. But that
could be an area we could invest in.
It's also worrisome if projects release updates that break other projects. The
simultaneous release helped with that by getting everyone to test the entire
stack being released. But I'm not sure how big a problem that really is and
hopefully allowing spontaneous maintenance releases can help fix those problems
quickly.
Doug
________________________________________
From: [email protected]
[[email protected]] on behalf of Stephan Herrmann
[[email protected]]
Sent: Thursday, September 24, 2015 1:37 PM
To: [email protected]
Subject: Re: [cross-project-issues-dev] Maintenance builds (was Announcing a
one week slip in the Mars.1 release (from 9/25 to 10/2))
Hi,
I don't see an easy solution but I do share Ed's concerns in this regard.
Is this just a packaging issue or an issue of content?
Aside from the Eclipse project, how many projects are actively
maintaining maintenance branches (no pun intended)?
Meaning: if we'd provide a channel for obtaining maintenance
updates only, what would be the content of the channel,
only platform updates?
Do projects with a lower offset within SimRel perhaps
care more about maintenance than "leaf" projects?
Honestly tell me: Is doing maintenance releases a relic from
the olden days in an ever accelerating world?
Stephan
On 09/24/2015 05:13 PM, Ed Willink wrote:
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
<<mailto:[email protected]>[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>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
_______________________________________________
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
_______________________________________________
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
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
