|Re: [eclipse.org-architecture-council] The Art of Project Release Naming|
Now I think establishing or promoting a standard set of guidelines is a good thing, on how and when version numbers should change. If that exists, then we are good to go and just need to promote it.
Dave Chris Aniszczyk wrote:
On Tue, Jun 30, 2009 at 6:04 PM, Doug Schaefer <cdtdoug@xxxxxxxxx <mailto: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 themajority 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 ------------------------------------------------------------------------ _______________________________________________ eclipse.org-architecture-council mailing list eclipse.org-architecture-council@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
Back to the top