Re: [sympa-fr] le futur de sympa vous intéresse t'il ?

[Philippe Gauron <adresse@cachée>]

Salut Marc,
ça me semblerait une bonne idée, et prendre 2 min pour le dire me semble 
bien le minimum que je puisse faire.

- Philippe.

Le 09/12/2020 à 11:44, Marc Chantreux a écrit :
> salut à tous,
>
> certains d'entre vous viennent de me signaler que cette discussion est
> *privée* ... ci-après une copie de l'échange à cette heure.
>
> si des gens sont prets a soutenir l'initiative, j'ouvre une issue
> demandant la création d'une branche stable avec du semantic versionning.
>
> Splitting branches?
> @dverdin
> dverdin
> 6 days ago
>
> Dear all,
>
> I discussed this by mail with Soji but I'd like to propose it here: Would it 
> be possible to split sable and development branches?
>
> Currently, Soji maintains Sympa almost single-handedly and the last thing we 
> want is to see him being crushed by work.
>
> But on the other hand, maintaining a Sympa with mixed refactoring, 
> improvements and bug fixes makes it difficult for user to follow the 
> releases, because sometimes, a bug arise.
>
> If we had two different versions, 6.2 as stable and 6.4 or 6.3 or whatever as 
> the next stable, it would allow to make deep changes in the development code 
> without fearing to break running instances, and we could still fix bugs and 
> security problems in the stable branch.
>
> Soji made it clear that he could not maintain both branches so somebody else 
> should maintain the stable branch. If no one more competent wants to, I 
> volunteer to do it.
>
> Also, I would support the idea of Soji being release manager for the 
> development branch, the future stable version.
>
> What do you think?
>
> Cheers!
> David
> @dverdin
> dverdin 1 hour ago Author
>
> Hi everyone,
>
> Indeed, @ikedas I did not quote you mainly because it was your thoughts, not 
> mine, so I preferred you publish them instead of me.
>
> I agree with @ldidry about the denomination. I talked about stable and 
> development because it was how we called it during the CRU / RENATER era. But 
> if you feel long term support / cutting edge suits better, I agree.
>
> To @racke : It is not that weird to have two branches. Most projects have a 
> stable release in which they only introduce bug fixes and an ongoing 
> development barnch in which they can make deeper and non reversible changes. 
> it does not change anything about workflow: you make quick bug fixes in the 
> stable branch to keep the stable version afloat and you make planned, long 
> term developments it the dev branch. It offers us the ability to break things 
> temporarily in the development branch if needed.
> About deep changes, I remember you wanted to introduce dancer and 
> DBIx::Class. Did you give up about this?
>
> In what I understand, until now :
>
>      @racke disagrees,
>      @ldidry agrees,
>      @ikedas agrees as long as he does not have to maintain the stable 
> branch. It is a good thing I proposed he stayed release manager of the 
> development branch and I or somebody else became release manager of the 
> stable one, then.
>
> Any other advice?
> @ldidry
> ldidry 1 hour ago
>
>      Any other advice?
>
> We need to talk about the tagging of the LTS branch. I propose 6.2.60-p1, 
> 6.2.60-p2, etc. (if the LTS is the 6.2.60, of course). The -p1, -p2, etc is 
> for patch-level-1, patch-level-2, etc. We could use 6.2.60a, 6.2.60b but 
> after 26 bugfixes releases, we would have a problem.
>
> Of course, we could also switch to semantic versioning instead, but I 
> remember that has already been discussed and was not accepted.
> @xavierba
> xavierba 20 minutes ago
>
> I would prefer to use numbers for the LTS: 6.2.60.1, 6.2.60.2, etc... But I 
> agree semantic versioning would be nice imho, including for the fast moving 
> branch, eg 6.3.0, 6.4.0 rather than 6.2.60, 6.2.62, etc...


--
- Philippe Gauron
Laboratoire de Physique des 2 Infinis Irène Joliot-Curie
UMR9012
Centre Scientifique d’Orsay, bât. 200, BP 34
91898 Orsay cedex
France

Attachment: smime.p7s
Description: Signature cryptographique S/MIME