To take some heat off EMF J, we do the same in the
CDT. What is best practices for some is not as good for others. The CDT does
not have a release engineering team. In fact, I am the CDT release engineer.
Since I have many hats, I do not have much time to spend on writing build
scripts and am reluctant to change them. So for us, not using the releng tools
and simply tagging and building all the plugins every build was easy to do, it
works, and I don’t have the time right now to change them. This is also
why I am against the pack200 thing BTW.
Now as the next simultaneous release rolls
around again next year, I think this is one area where we could really reduce
duplication in the projects and streamline things. I would like to propose that
we have one release engineering team, with maybe participants from various
projects, working on one single set of build scripts and a single simultaneous
build. This would solve a lot of problems, including the lag we have between Platform
build and Callisto release, and it would make it easier for us to line up with “best
practices”. On the negative side, there is much more chance for these
builds to be busted as API changes occur in the lower bits, but then I think
that would also force the lower bit teams and the upper bit teams to
communicate more.
Any, just a thought and sorry for not
following “best practices”.
Cheers,
From:
cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: Friday, April 28, 2006 12:23
AM
To:
cross-project-issues-dev@xxxxxxxxxxx
Subject:
[cross-project-issues-dev] Best practices on versioning
I thought I'd post this here, for a "wider"
education (either mine or others :)
I've
noticed one project (EMF) that appears to version all their features and all
their plugins, in the 4th place qualifier field,
to
match the date and time of their builds. On the one hand, this is nice to tell
what goes-with-what in directory lists, but its counter to
"best
practices" on feature and plugin versioning, right? Shouldn't
features and plugin versions (and qualifiers) change only when the
code
really changes? Perhaps EMF really does change each and every one of their
features and plugins each build ...
nah,
I'm sure they don't do that. So .. is this a long term plan? Just a short term
tactic?
I
thought I'd ask here, publically, in case there is a reason for this I'm not
aware of ... so we can all be educated.
The
problem this strategy poses is that with something like update manager, it
means users/developers might end up (re) installing code that
hasn't
really changed. So .. sure EMF is a tiny project :) ... but, I hope this
doesn't become widespread practice, or the new
versioning
rules won't accomplish as much as it could. For one documented scheme on
versioning rules see
http://www.eclipse.org/equinox/documents/plugin-versioning.html
We
in WTP are attempting to following this too.
Do
other projects have other, different schemes?
And,
I hope well known, I don't mean to "pick" on EMF .. I have not really
looked at many others projects schemes, but just noticed
EMF's
practice, and thought I'd ask here in the interest of development in the
open.
Thanks
in advance for any clarifications.