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