Le 06/10/2016 à 08:08, Moron, Olivier a écrit : > Hello, > > Ok for me, sounds good, apart the word “backport” which seems to be > bizarre when speaking about 9.1/bugfixes -> master (I would prefer > cherrypicked or ported), and also for master -> master (I would prefer > Pull Request?). For me “backport” means a port of a modification (fix or > evolution) into a previous version, and not into a future version.
I Agree about confusing wording. > Regards, > > Olivier > > > > -----Original Message----- > From: Glpi-dev [mailto:glpi-dev-boun...@gna.org] On Behalf Of Johan > Cwiklinski > Sent: Wednesday, October 05, 2016 9:44 PM > To: Liste de diffusion des developpeurs GLPI > Subject: [Glpi-dev] Branching rules > > > > Hello all, > > > > There is one "important" point I've documented on the dev doc, regarding > to branching for features and bugfixes. > > > > What I propose is: > > - to fix a bug on the stable release, the work must be done on the > 9.1/bugfixes branch (for now), and must be merged back to this one; and > then backported to master > > - to fix a bug on the next release (master), the work must be done on > master and backported to master only. New feature ? (master of course) Which also mean, beta/RC should be tagged from the version branch, as this means the version enter "stabilization" phase, and so, feature freeze. ie: at some point in the future - branch 9.2/bugfixes - tag 9.2RC1 from it - master becomes 9.3dev We probably also need a "String freeze" for translators. Remi. > > > > This workflow should prevent parts of master code to be backported to > the bugfixes branch, what would be a real issue. > > > > For features, well, this concerns only the next release, and that will > reach master only; no problem. > > > > Do you agree with this workflow rules? Have you any comments/suggestions? > > > > For the short story, github make possible to change the destination > branch once a PR has been opened, so it should not be an issue... But > changing from master to 9.1/bugfixes will try to add other commits from > master... Contributor will have to rebase on the correct branch on his > side. Sounds like a GH bug (or thing I do not understand -- that's the > same, isn't it? ;)). > > > > I just want that to be clear for everyone. > > > > Regards, > > -- > > Johan > > > > _______________________________________________ > > Glpi-dev mailing list > > Glpi-dev@gna.org <mailto:Glpi-dev@gna.org> > > https://mail.gna.org/listinfo/glpi-dev > > > > _______________________________________________ > Glpi-dev mailing list > Glpi-dev@gna.org > https://mail.gna.org/listinfo/glpi-dev > _______________________________________________ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
