Hi Christian
I'm told that OOMPH (formerly CDO tools) can manage versions
automatically. Problem solved.
If you're proceding manually, I find that even on almost single
committer projects, safe version maintenance is too hard. With
OOMPH being clever with versions in P2 caches, any version errors
could be very confusing or worse.
A specific hazard is
Master. plugin B gets a real bug fix. + 0.1.0
Maintenance. plugin A gets a compatibility bug fix. +0.0.1.
But, the maintenance fix is not needed on master where the fix
was more powerful.
Result current-master-version-of-A <
current-maintenance-version-of-A.
I find that the only manual solution is to add +0.0.100
proactively before any development occurs, then add +0.1.0 lazily
when actual changes occur.
Another hazard occurs with the staggered timing of maintenance
and milestones publication. A maintenance version may overtake
wiith a +0.0.1 until the subsequent milestone restores consistency
with a +0.1.0.
A similar hazard occurs if you want to investigate an Oxygen M2
phenomenon after Neon.2 is available. Neon.2 can replace some of
the Oxygen M2 content unless the M2 content advanced proactively.
IMHO Papyrus has too many committers to expect that they can all
be diligent at all times.
Regards
Ed Willink
On 23/06/2016 13:34, Christian Damus
wrote:
Hi,
Team,
Now
that we are following the usual Eclipse versioning guidelines
for plug-ins and features as of Papyrus 2.0, have we decided how
we shall address the incremental update of versions? There are
at least two possibilities:
- update bundle version if necessary for each first change
made in a bundle. Ripple the change up the chain of
containing features
- wait until later to analyze all changes made since the
previous release and update bundle and feature versions
accordingly. This would have to be done at a minimum before
every milestone build
I would definitely advocate for the former, because it is easier
to make these changes on the spot when their nature is clearly
understood and fresh in the memory. Especially as there are so
many different kinds of version changes in play:
- 1.2.1/2.0.1/etc. for bug fixes on the maintenance branch and
on master if cherry-picked from maintenance (same fix on both
streams)
- 1.2.100/2.0.100/etc. for bug fixes implemented only on
master (not cherry-picked from maintenance)
- 1.3.0/2.1.0/etc. for new features
- 2.0.0/3.0.0/etc. for breaking changes
We
have already been making some changes on both streams, and I
think it would be best to settle this question now before we
get too far behind in tracking these changes. For myself, I
have so far made two fixes on the Neon maintenance branch
for which I am working on Gerrits to update versions:
https://git.eclipse.org/r/75833
What do y’all
think?
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev