| [higgins-dev] RE: Re: Higgins version numbering |
|
Yeah, that's not going to work, sorry. The term "Release" and the
release numbering is one of those few important things about Eclipse -
it's a convention/rule that helps the Eclipse ecosystem understand the
stability and compatibility of various versions of a framework. However, all is not lost: I think you're just talking about milestones: 1.1M1, 1.1M2, 1.1M3, ... . If you are just building milestones every six weeks towards a larger release, then use the Mx build naming and everyone will be happy. If you are truly releasing a new official "release" every six weeks that includes new features, then we need to talk because each official release needs to have a Release Review (announced, scheduled, public, the whole thing). The only exception to that rule is for bug fix releases 1.0.x where the bug fix release does not contain any new features. - Bjorn Sigh. Yes, we did know this. Here's the problem. Higgins is a large enough project that if we were to follow the Eclipse convention at the overall Higgins level we'd be going from Higgins 1.N to Higgins 1.N+1 every six weeks or so. Our March 28th release would be 1.1. At least some of us believe that doing so would send a message that Higgins was completely unstable. Which isn't quite fair. In any given release we estimate that MOST of our APIs wouldn't change in any externally visible way, a few just add non-breaking features, and maybe one or two would introduce a breaking change. Further, we have several top level "solutions" (our term) each of which uses different combinations of projects, etc. Our proposed compromise was to use Eclipse numbering conventions for each of the constituent projects, but not at the overall Higgins Project (capital P) level. --
[end of message] |