Hello all,
last several years I did Yade releases and the process was
the following. Before the release was done I created the corresponding
release-branch (for example 0.60 [1]) and just tagged the new
Yade version there. It worked relatively good.
--------------------------------------> develop
\ \
\ \
\Release 1 \Release 2
\Release 1.1
I can remember only a couple of times, where the hot-fixes were
needed to be integrated into the release-branch due to some serious
stability or functionality issues.
Last years I have an experience of work with master-develop
approach. It is not bad. But you really need to know, why do
you need it.
I am fully support the feature-branch + merge request way of working.
It can really help to double check the code and implement some
additional tests.
[1] https://github.com/yade/trunk/tree/0.60
My 2cts....
Regards
Anton
Am Mo., 7. Jan. 2019 um 17:39 Uhr schrieb Janek Kozicki <janek_li...@wp.pl>:
>
> Bruno Chareyre said: (by the date of Mon, 7 Jan 2019 16:59:53 +0100)
>
> > Daily builds would be based on the develop branch.
>
> good, that answer my question from other mail.
>
> > > (by the way, with a tighter control on development, would we still
> > > need a distinction between "yade" and "yadedaily" packages ?..)
> >
> > Yade is stable release, not updated very often, included in main
> > debian/ubuntu repos.
> > Yadedaily is updated more than daily, after each change to the source
> > code, not included in debian/ubuntu repos.
> > They are very different things and I think we need both.
>
> agreed.
>
> > > Also, with "develop" and "master", I guess any proposal for code
> > > modification would have to be closely examined and validated twice :
> > > - once to make it into "develop"
> > > - and once, to make it from "develop" into "master"
> > > ?...
> > There is no reason to check the develop->master merge if everything in
> > develop is already validated by regtests + human review.
> > Our github/master corresponds to "develop" more or less.
> > Merging develop into master in the new model would correspond to Anton
> > calling for update and releasing 2018.b. More or less.
>
> agred.
>
> > We probably need a liberal, truly unstable repo on the top of this, at
> > least in a transitory phase, so that everyone can play with gitlab a bit
> > and break everything with no limit. For instance to compare --no-ff,
> > --only-ff, and other variants.
>
> how about calling it experimental ? :-))
>
> And yes, we definitely need something like that.
> Where git reset --hard is nothing to be afraid of.
>
> --
> Janek Kozicki
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-dev
> Post to : yade-dev@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~yade-dev
> More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
