Thanks, Patrick,
I appreciate your quick response. If I go ahead with that scheme for now (and you likewise, I think? You have some changes blocked as well?) then we have lots of time still in Oxygen to amend the versions on the master branch when we have a clearer view of the policy for continuing maintenance on Neon (or not) after the Oxygen release is published. We can even add 10 to the minor version later on the master branch if that’s what we eventually decide.
But I must say, I’m not sure that I like the notion of adding 10 in the minor version for Oxygen. Yes, it has the same benefit as the +100 in the micro version to let the least significant digits match up with the similar versions on the maintenance stream, but when the greatest of the 2.11/2.12/2.13/etc. version numbers that we end up with across all of the Papyrus bundles in Oxygen bubbles up to the root feature (org.eclipse.papyrus.uml.sdk), then I think it sends some pretty confusing messages to consumers. It looks like ever so much longer a way from 2.0 in Neon.0 and 2.3 in Neon.3 to 2.13 in Oxygen.0.
My own preference would still be to cap maintenance releases, or at least new feature content/APIs in maintenance releases, on release of the next version. This obviates the +10 inflation in the minor version.
cW On 12 July, 2016 at 01:50:03, TESSIER Patrick 202707 (patrick.tessier@xxxxxx) wrote:
Hi, Remy is not present this week.
But I agree for the proposition: “ x.y+1.0 in the maintenance branch and x.y+2.0 on master”
Patrick
Can we please come a decision on this question now? Do we need to have a conference call?
I have work [1] [2] [3] that is blocked on this decision, that Papyrus-RT is depending on. If we don’t make a decision this week, I’ll proceed with the proposal that I set
out: x.y+1.0 in the maintenance branch and x.y+2.0 on master, on the assumption that we will always keep master a step ahead while it is in development.
On 8 July, 2016 at 18:24:33, Christian Damus (give.a.damus@xxxxxxxxx) wrote:
See some comments in-line, below.
On 8 July, 2016 at 04:00:51, SCHNEKENBURGER Remi 211865 (remi.schnekenburger@xxxxxx) wrote:
This is also the topic discussed on the components area for Papyrus. It would be really
useful for them to have more frequent releases, especially from the core Papyrus. As for example, Papyrus-RT currently targets the Neon.1, as it needs some updates on the core Papyrus.
What do you mean by the components having more frequent releases “especially from the core Papyrus”? By components do you mean features like Designer and SysML 1.4? If so, how they go through
Release Reviews if they aren’t projects in the Eclipse Development Process?
The “issue” with that is to ensure a quality level / robustness and very clear API management
(not only java for example, but also configuration models, etc.). That means that for subprojects as Papyrus-xtUML and Papyrus-RT, we must ensure that the customizations are stable enough to let them adopt new features, while still having a comfortable level
of performances / robustness, and without requiring too much migration efforts. It is quite OK to be fast evolving when we are a leaf component, with no more projects depending on you. This is a bit harder when the project is reused by several sub-projects.
Yes, I agree. Especially considering the state of the APIs in Papyrus (in terms of stability, coherence, public/internal visibility, etc.) it seems better to have a longer release cycle in
which to iron out the details.
So, with all of this considered, how do we arrive at a decision about how to update versions on the Neon.x and Oxygen streams? I have the same need as Patrick to make sensible version updates
in several plug-ins for new APIs that are needed by Papyrus-RT, in both the RSA Model Import and in the workspace model indexing subsystem.
Regards,
Rémi
-------------------------------------------------------
Rémi SCHNEKENBURGER
+33 (0)1 69 08 48 48
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
 www.eclipse.org/papyrus
Projects such as CDT are planning now to make more frequent (even quarterly!) feature releases, so
that the maintenance streams are hardly relevant any more. That appeals to me. And this was a major driver in the Simultaneous Release train’s move to four quarterly follow-up releases that are no longer couched as “maintenance” releases but may contain
new feature content and even new projects.
Papyrus is such a quickly-evolving creature that I think we should seriously consider making quarterly
feature releases and re-thinking the maintenance program.
On 7 July, 2016 at 11:00:04, Ed Willink (ed@xxxxxxxxxxxxx) wrote:
Hi
On 07/07/2016 16:26, Christian Damus wrote:
This is why other Eclipse projects cap their maintenance streams when the next release is published.
We should now do the same.
That certainly would solve the problem, but how do you plan to handle the very real customer pressure for
updates? OCL has released 5.0.4 and 5.0.5 after 6.0.0 in order to satisfy Papyrus customers. This would have been difficult without the proactive +0.0.100.
Regards
Ed Willink
|
|
This email has been checked for viruses by Avast antivirus software.
www.avast.com
|
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
|
