Hi, Ernesto,
The name “1.0.1” would be confused with the eventual tag of that name, so that a checkout command would be ambiguous.
Could we name it “1.0-maintenance”, instead, as is commonly done in Eclipse Modeling Projects (at least UML2 and Papyrus)?
On 24 May, 2016 at 11:08:50, Céline JANSSENS (celine.janssens@xxxxxxxxxxx) wrote:
Hello Ernesto,
Good Idea, i'm going to create a specific Job gerrit for this
Branch !
Regards
Céline
Le 24/05/2016 à 16:57, Ernesto Posse a
écrit :
Hello. I didn't hear from anyone else, so I created
a new branch called "1.0.1".
This branch is intended to be temporary. The idea is that
before release, commits on master should be bug fixes, and anything
that is a new feature should go on this 1.0.1 branch.
On release we'll rename "master" as "maintenance" or
"release", and we'll rebase "1.0.1".
Sounds good?
Ø
While it's true that between feature freeze and
release we should focus on testing and fixing bugs, I think having
a branch that fully builds new features could be helpful and
simplify the integration of new features once we release. I'm not
sure I like having pending changes hanging on Gerrit particularly
in the case where there is more than one Gerrit on top of another,
which become a pain to merge later on. And I also prefer having few
items in my Gerrit dashboard ;)
I agree; that’s exactly why we wanted to experiment
this for the Neon/Oxygen transition. As it happens, the Oxygen
branch has not been used yet, but at least we have a place where
new features can be integrated, built and tested if we ever need
it
Ø
In fact, the "anti-gitflow" approach advocated
in [2] seems to be closer to what you describe:
Much closer indeed, except for the “Release” part of
this article: our Maintenance branches have to evolve in parallel
to the master branch, so they remain forever, and we indeed have
duplicate (“cherry picks”) commits between Maintenance and Master
branches. We can’t merge these branches, because versions evolve
independently (e.g. when Mars moves from 1.1.0 to 1.1.1, Neon M1
goes from 1.1.0 to 1.2.0. Also, some fixes involve breaking APIs,
so we usually implement a quick workaround for the maintenance
branch, and a proper, larger fix on master). So we actually need
maintenance branches that remain forever.
Regards,
Camille
De :
papyrus-rt-dev-bounces@xxxxxxxxxxx
[mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part
de Ernesto Posse
Envoyé : mardi 17 mai 2016 21:31
Objet :
Re: [papyrus-rt-dev] Feature freeze and git repo
I like the idea of a temporary branch for new
features, a little bit like in the gitflow model [1], although that
seems to use a merge approach rather than a rebase approach like
us, and it has its drawbacks [2].
In fact, the "anti-gitflow" approach advocated
in [2] seems to be closer to what you describe: consistent with the
goal of keeping a linear history, making other branches temporary,
creating a branch for the release (i.e. the "maintenance" branch).
That sounds good to me.
While it's true that between feature freeze
and release we should focus on testing and fixing bugs, I think
having a branch that fully builds new features could be helpful and
simplify the integration of new features once we release. I'm not
sure I like having pending changes hanging on Gerrit particularly
in the case where there is more than one Gerrit on top of another,
which become a pain to merge later on. And I also prefer having few
items in my Gerrit dashboard ;)
So if we are voting, I'd vote for having a
feature branch, renaming 'master' to 'maintenance' after release
and rebasing the feature branch.
Hi,
In Papyrus, we don’t switch branches until the final
release (Which is RC4 for us). Any new feature is postponed (e.g.
pending on Gerrit) until the release is complete. This is mainly to
avoid reconfiguring the build & scripts due to switching
branches.
We’re however experimenting a new approach this year:
we’ve created a new branch after Feature Freeze (M7), for the next
release. This is a temporary branch, that will be rebased to master
after the final release (RC4). Once the branch is rebased, the
current master will be renamed to maintenance, and the rebased
branch will become the new master
The point with this approach is to be able to push new
features on a dedicated branch, where we can have complete
builds/validation, and we can merge several features on the same
branch to identify conflicts early, without changing the current
structure for the master branch (Same branch name, same build
configuration...)
We don’t have too many contributions on this new
branch, so it’s hard to tell whether it was useful at all. In
general, at this time, we should be focusing on bug fixes anyway;
not on features for the next yearly release. So, I’d say, new
branches can wait :) but it really depends on your plans and
contributions
Regards,
Camille
De :
papyrus-rt-dev-bounces@xxxxxxxxxxx
[mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part
de Ernesto Posse
Envoyé : mardi 17 mai 2016 02:32
À : papyrus-rt developer discussions
<papyrus-rt-dev@xxxxxxxxxxx>
Objet : [papyrus-rt-dev] Feature freeze and git
repo
Since we have feature freeze this Friday, I
was wondering how are we going to deal with it in the git repo. Are
we going to create a "1.0.0" branch and continue 1.0.1 development
on master, or are we going to create a "1.0.1" branch and let
master be 1.0.0 with only bug fixes committed on it, or something
else? What does Papyrus do?
--
_______________________________________________
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
--
|
Céline JANSSENS
Software Engineer
+33 (0)2 44 47 23 23
|
|
Mail : cej@xxxxxxxxxxx
|
6 rue Léonard De Vinci - BP 0119 - 53001 LAVAL Cedex - FRANCE
www.all4tec.net |
|
_______________________________________________
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
|