+1 Good point.
Hi,
As you said, we are in incubation. I think it's worth spending a bit of time to experience these actions, so the process for creating and maintaining this dev environment is tested, known by developers and documented. Better to train and experiment now than
when we will be out of incubation! For example, is our build process able to easily shift the configuration to a different branch?
Regards,
Rémi
My view on this, for what it’s worth, is that we need not worry about a 0.8.x maintenance branch until we have a need for one.
We are still in incubation and we should first consider documenting most issues we encounter either as a release note or as a FAQ.
IF I must state criteria, I would say that we would need a 0.8.1 if
- There is a major problem preventing multiple users from installing the product.
- There is major problem with Papyrus-RT that would prevent multiple users from accomplishing basic UML-RT tasks.
/Charles
Hi,
Do we have a clear idea of what the criteria are for deciding what bugs need to be fixed in a maintenance branch? As I understand it, the 0.9 release is planned
for the middle of December It hardly seems worth the overhead of duplication of builds, setups, commits, testing, etc. for 0.8 maintenance.
On 26 October, 2016 at 10:50:11, SCHNEKENBURGER Remi 211865 (remi.schnekenburger@xxxxxx) wrote:
Yes,
That would allow the integration of the waiting gerrits on the eclipse server. As soon as the release has been done, we enter on the release maintenance
period for 0.8. That also means the job duplication on the Hudson server – one set for master, the other set for streams/0.8-maintenance branch. This has the side effect for developers working on the maintenance branch not to forget to backport the fixes on master (or work on master and then
backport on streams/0.8-maintenance)
And this may also require some action on the oomph setup model, depending if we are working on the master or on the maintenance, and so to update
the documentation on the developer side of the wiki.
Regards, Rémi
-------------------------------------------------------
Rémi SCHNEKENBURGER +33 (0)1 69 08 48 48 CEA Saclay Nano-INNOV Institut CARNOT CEA LIST
<image001.png@01D22FA8.B9EF3AC0>www.eclipse.org/papyrus
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De
la part de Ernesto Posse
Envoyé : mercredi 26 octobre 2016 16:39
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] git tags for releases
And should we also create a maintenance branch for 0.8?
Perhaps streams/0.8-maintenance?
I would assume that we would do 0.9 commits on master and 0.8.1 on streams/0.8-maintenance.
No objections then to calling it "releases/0.8.0"?
Any other opinions? ...going once...
My own preference is for the releases/0.8.0 shape because several git UI tools on Mac show slash-separated branch and tag names as collapsible
nodes in a tree.
On 24 October, 2016 at 14:55:31, Ernesto Posse (eposse@xxxxxxxxxxxxx)
wrote:
Hi everyone.
Since we have now released 0.8.0, we should create a tag in the git repo.
There is one question: what do we call the tag? For the previous releases we have just the version number: 0.7.0, 0.7.1 and 0.7.2. We could keep
the same scheme, or we could do something more descriptive, like
With a more descriptive tag name, we could also have corresponding tags for milestones.
Any comments? suggestions? preferences?
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev
mailing list
papyrus-rt-dev@xxxxxxxxxxx
To
change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________ papyrus-rt-dev mailing list papyrus-rt-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
|
