Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] ECF versioning for next release 
Hi Chris,

Chris Aniszczyk wrote:
On Tue, Jun 30, 2009 at 2:53 PM, Scott Lewis <slewis@xxxxxxxxxxxxxxxxx <mailto:slewis@xxxxxxxxxxxxxxxxx>> wrote: 

    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).
Yes. I would also like to see ECF adopt PDE API Tools across its bundles to ensure versioning is encoding API compatibility.
For the most part this is already the case (i.e. almost all bundles are already using PDE tools). If someone wants to go through and verify this for all bundles...and add PDE tooling for the ones missed...this would be a good thing to verify (on HEAD stream please).
We do need to move to consistently using ECF 3.0 as the baseline (as it has been 2.1...at least in my environment), but that's easily done now that 3.0 is out.
The only thing API Tools won't help you with is the micro version, but that one is easy. 

    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
My vote is for ECF Helios. I believe this is a pattern other projects should be following too.
Is this some sort of pattern emerging among simultaneous release participants? If so, please detail (or point to something) on the bug 282068. 

Scott

Back to the top