Best practices on versioning
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
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”.
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of David
Sent: Friday, April 28, 2006 12:23 AM
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
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. _______________________________________________
cross-project-issues-dev mailing list