+1
Ok, so it is agreed then?
1) Create a streams/0.8-maintenance branch on the current head
2) Create a releases/0.8 tag on the current head
(I can do it)
That sounds fine. Better not to delay creation of the branch until multiple developers all need it and have to decide which one should create it or, worse, all create it independently. 😀
At least the second suite of build jobs would be able to roll over for the next maintenance stream, 0.9.x, 1.0.x, etc. in turn because there would always be only the “previous release maintenance” active. So we won’t expect to have three, four, nine sets of
similar builds jobs.
On 26 October, 2016 at 11:22:12, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
So how about if we just create the branch but don't do any of the supporting build infrastructure until (and if) it is actually needed?
If there are really urgent bugs for early adopters/customizers, then we can do the additional work then.
We could also just create the tag and not the branch and only create the branch until we actually need it.
Hi,
Given the current plan, i would indeed expect that a few bugfixes should be pushed to the stream/0.8-maintenance branch. It would be indeed costly to work on both branch. But for the early adopters/customizers, i would expect the need of only small but important
fixes (priority of the viewpoint for example) on the stable branch.
Regards,
Rémi
Objet :
Re: [papyrus-rt-dev] git tags for releases
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
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@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
|