Skip to main content
[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
The XSL Tools wst.xsl component uses PDE API Tools...caught some potential issues I had to fix when going to the next version of the PsychoPath processor. Anyways, I think we have to be careful tying things to the release train. Reason being is that projects may want to release more often than once a year. I know for more established projects they can deal with a yearly release as their only release, but there are reasons to release more often, and a project should have that flexibility.
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 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
------------------------------------------------------------------------

_______________________________________________
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