+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
|