Re: [ajdt-dev] Feedback requested: AJDT versioning

[Andrew Eisenberg <andrew@xxxxxxxxxxxx>]

Hi all,

I'm coming back to this a little late.  Thanks for all the feedback so far.

My thoughts are that although we have been sticking to the 1.6.x
stream for the entire year we have made significant improvements to
AJDT that probably would have justified a major or minor version
increase.  Some of this has included breaking API changes (for example
the change to using a native AspectJ cross referencing model instead
of an AJDT copy).

Another side of the issue is maturity.  Although we are going to
continue to make improvements to AJDT (and AspectJ), we do not foresee
any major rewrites or reworking of existing code (like we have done
this past year).  Future improvements will likely be adding AspectJ
specific refactorings, better crosscutting support for inpath and
aspectpath, and other "finishings".  This will mean that the existing
API will likely remain stable (with additions possible, but changes
unlikely).



With all this being said, I am leaning towards going with option 1
above and releasing 2.0 and 3.0 this June around the time of Eclipse's
Galileo release.  This gives us a chance to wipe clean the previous
versioning system, which really isn't working very well from my point
of view.  With this approach, we can be more clear about what releases
mean:

1. Major release X.0.0 coincides with a new Eclipse release.  It will
be incompatible with prior releases.
2. Minor release 2.X.0 coincides with some new functionality or
non-breaking API change
3. Micro release 2.0.X coincides with mostly bug fixes or small
changes to functionality.

Major releases would be on a yearly cycle, with approximately 4 minor
or micro releases a year.  I don't want to commit to a certain number
of micro or minor releases because in my experience, 4 months can go
by (eg- between 1.6.2 and 1.6.4) where there were many bugs fixed, but
no new functionality was added.  So, I don't want AJDT to commit to a
minor version increase when a micro version is sufficient.
Furthermore, it is good to keep open the possibility of pushing out
additional micro releases when critical bugs are found and fixed (this
is what happened when 1.6.3 was release 2 weeks after and 1.6.2).
Under this new scheme, we can better communicate these subtleties.

The problem with my proposed versioning scheme is the confusion that
may occur when we bump up to 2.0  without a breaking change.  So, an
alternative proposal (that I am less fond of, but am willing to
consider) would be this:

1. Next version of AJDT for Eclipse 3.4 is 1.7
2. Next version of AJDT for Eclipse 3.5 is 2.0
3. Same major/minor/micro scheme as above.

The problem with this proposal is that since we have been calling AJDT
for 3.5 version 1.7, we are introducing another layer of potential
confusion.

I am going to make a decision on this tomorrow afternoon (Friday,
Pacific time).  If you have any more input, please reply before then
(or you can send me email directly).  Please let me know which scheme
you like better (2.0 and 3.0, or 1.7 and 2.0), or give me a reason why
neither are good.

Thanks for your input so far.

--a