| Re: [ajdt-dev] Feedback requested: AJDT versioning |
|
I agree with Martin on the
API point to the extent that there should be binary compatibility for
the minor versions. I don't think that the 1.x version number is seen as 'immature' any more than I really think that Mylyn is mature due to it being v3.1 or TPTP being better than YourKit cos it's a higher version. I do think there's a legacy relating to the JDKs and AJ versioning, which isn't that helpful and it would be more informative for an IDE tool for it to relate to it's JDT counterpart. I think we should increment major versions when the user would expect them, for example: - an indication to new users that there is something new, worthy of being in a New and Noteworthy document (i.e. 3.5 has N&Ns, but 3.4.2 naturally doesn't). I think we should increment the major number when that changes (the change to the JDT weaving would therefore have been 1.6.x -> 1.7. In AJ, the intro of @DeclareMixin would have equally been a notable change). - an indication of API changes. I think this is more of an issue for AJ than AJDT, although I guess it would be good to be able to be able to update AJDT core without updating the cross refs view etc. I suspect those should update independently really. In addition, let's look backward and forwards: We could have had a major version change when the weaving service was introduced. As far as I understand, it was a significant change to the API for people adopting AJDT, but probably more important to them would have been the change in documentation. We should ensure that AJ and AJDT are UI and API-predictable for adopters. I would be interested to hear feedback from people working on MyEclipse, JBuilder, and other Eclipse-based IDE distros. So far, it seems that no-one has done anything to annoy any of them, but that probably means that neither is building commercial products on top of AJDT. Most significant in terms of adopters is probably SpringSource's commercial offerings, which I've heard we have connections to ;) I'd suggest that Spring give some input of requirements. Going forwards, I think it would be good, both with AJ and AJDT to have some ability to push new API and even have some risk of breaking someone's use of assumed API. An example I discovered is the change I'd like to see on the weaveinfo messages. That change would impact Spring users, and it's something I'd consider part of clarifying the API to, in that case the AJ weaver. While it may be a bit more overhead for the build management, I think it would be good to create the room to be bolder. To a great extent, I'd say that AJ and AJDT only operate a maintenance branch, where the e3.5 code during the last year ought to be something that stimulates more adventurous input. Perhaps a good aim for e4 would be to release AJDT builds with the milestone builds, from an advanced branch. In that respect, it seems that defining the API more rigorously would help. Perhaps it's worth doing a bug triage, and tagging [api] to get a sense of what we may be holding back on due to breakage concerns. I think we could and should be bolder and look to the long term with the e3.5 stream, especially in preparation for e4, were I see no reason not to expect significant changes in IWorkspace, IWorkbench, IProject etc. Minimally for e4, I hope to be seeing native support in JDT for test source and output folders, and support for flexibility in the location of .project .settings etc. These will impact AJDT. As for 3.4 vs 3.5, that's a challenge. What are the plans after 3.5 is released? Will the 3.4 release (i.e. 1.6.x as currently stands) get new features back ported, or just requested bug fixes for people stuck on an old release until MyEclipse, JBuilder, Rational etc update to 3.5? Cheers, Neale On 22/04/2009 07:47, Martin Lippert wrote: Hi! |