[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-architecture-council] The Art of Project Release Naming
|
On Tue, Jun 30, 2009 at 6:04 PM, Doug Schaefer
<cdtdoug@xxxxxxxxx> wrote:
I don't know if the CDT is a good example to follow. We increment the major number when we think there will be some major architectural changes in the upcoming release, and especially if APIs are going through major changes. And we usually get it backwards, 3.1 introduced the new indexing framework and CDT 5.0 didn't introduce much. But starting in CDT 6.0 we are managing the bundle versions per API change rules.
I didn't mean to pick on CDT, it was simply the example that springs to my mind. I'm glad to hear that CDT will be managing bundle versions per API change rules... it's my hope that the CDT team adopts PDE API Tooling :)
When I ran the API Tooling Usage Scan across the Galileo release... I was sad that only a few projects actually adopted API Tooling to help with them managing versions. From that, I deduced that many projects weren't simply managing their versions properly.
The CDT also predates the train so people are used to thinking about it with it's numbered version and not by the train name. Maybe the EPP package will change that, but I'm not getting a lot of love for the C/C++ EPP package from the committers. We're the perfect example of vendor over user, and the vendors don't use the packages.
But anyway, don't use us as an example and do what's right for the majority of the community. Naming by train name is the right approach, unless you are not totally on the train and have minor releases inbetween.
If other people think this is the right approach, should we as the AC, recommend this to projects? In my opinion, it makes it easier to talk about the projects when it comes to release time.
Cheers,
--
Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
http://twitter.com/eclipsesource |
http://twitter.com/caniszczyk
