Hi, Team,
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:
Hi, Rémi,
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
|