[ecf-dev] ECF versioning for next release

[Scott Lewis <slewis@xxxxxxxxxxxxxxxxx>]

Hi Folks,

Markus K and I were on the conference call this  am (Tues, June 30 1500 
UTC), and we discussed ECF versioning for the next release cycle(s).

We came to some basic conclusions

1) It's possible (and our case desirable) to logically separate 
*project-level* versioning strategy, from *bundle-level*/API version 
numbering.  That is, if we need to make backward compatibility-breaking  
changes in a given bundle/API (e.g. 1.0.0.qualifier to 2.0.0.qualifier), 
then this does *not* require that the project-level version must also be 
incremented (i.e. 3.0.0.qualifier to 4.0.0.qualifier).   In effect, this 
gives us more flexibility for both handling project-level naming and 
dealing with different levels of maturity for our own APIs (i.e. 
remoteservices, discovery, shared object, core, call, datashare, 
presence, presence bot, various providers, rfc119, etc).

2) Given 1, for our *project-level* versioning, we are free to choose 
from a number of possibilities...including not having a version number 
at all, but rather a name for the version...e.g.
   a) ECF 3.1
   b) ECF 4.0
   c) ECF Helios
   d) ECF 6.2010
   e) others...

For background, see some of the discussion around this thread on the rt 
pmc mailing list:  
http://dev.eclipse.org/mhonarc/lists/rt-pmc/msg00716.html.  We don't 
have to immediately decide upon our project-level naming for next 
release, but I've created this bug to use for discussion, idea-tracking 
over the next few months:  
https://bugs.eclipse.org/bugs/show_bug.cgi?id=282068

3) For *all* our non-provisional APIs, the default assumption should be 
that only minor version changes will be needed/planned...and only if 
there is appropriate justification will we consider making major API 
changes (i.e. actually invoking 1).

4) As per 3, if we *do* have to consider introducing a major API change 
(at bundle/API level), then this needs to be vetted by the community 
prior to introducing the release...e.g.
   a) Bringing up on mailing list and newsgroup
   b) Making plans and justification known to all community members in 
other ways (e.g. blog postings?, home page news, wiki, etc)
   c) Discussing with other committers via conference call
   d) Providing written explanation for all community members to review
   e) Possibly having a set of meetings/presentations among committers 
and community members (on case-by-case basis)
   f) Providing migration support (e.g. docs) when necessary/appropriate.
   g) Other things...
Basically, the idea here is that we need to communicate clearly and 
repeatedly with the community and all known consumers *prior* to 
introducing breaking API changes.  We have flexibility as to how we do 
this, and what resources are involved, but we definitely need to do as 
much community outreach as we can manage *before* introducing any 
API-breaking changes.

5) For some of ECF's APIs (specifically the ECF core and filetransfer 
APIs), if any changes are desired they have to be cleared with the 
Eclipse p2 team and Eclipse PMC, since p2 depends upon these APIs.  Just 
to be clear:  at this point there are no plans to make changes to these 
APIs in the coming release cycle, but if that changes/becomes necessary, 
all such changes will have to be approved by p2 team/Eclipse PMC as well 
as by me as project lead and the rt pmc.

6) Development on our next release cycle will occur on HEAD.  When we 
decide upon and then do releases over the next cycle, we will create 
branches for each release before the actual release (as we have been 
doing), so that we can have a branch for service releases.  Committers, 
please keep in mind that bug fixes over the next few months need to be 
applied to both the Release_3_0 branch and HEAD.

So I think this email is long enough as it is...if there are questions 
at this point for any of the above please ask them, and we'll have more 
discussion.

Scott