[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [higgins-dev] Re: Higgins version numbering
|
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.
-Paul
________________________________________
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Bjorn Freeman-Benson
Sent: Sunday, March 09, 2008 10:32 PM
To: higgins-dev@xxxxxxxxxxx
Subject: [higgins-dev] Re: Higgins version numbering
Paul,
Note that pre the Eclipse numbering terminology, a 1.0.1 release is a bug
fix release and contains no additional or new features. So if you are
planning to add features or functionality, you'll need to go to 1.1 rather
than 1.0.1. I'm sure you already knew this, but I thought I'd mention it
anyway.
FYI,
Bjorn
OTOH for Higgins as a whole (entire "Higgins releases") I describe an
independent numbering scheme (e.g. 1.0.1, 1.0.2, etc.).
--
[end of message]
