Re: [Tiki-devel] The Tiki lifecycle is optimal (since 2018)
Jonny Bradley via TikiWiki-devel <[email protected]>
| Newsgroups | gmane.comp.cms.tiki.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Roberto I suppose i was thinking of a minimum release frequency, like at least every 6 or 8 months but more often if necessary for emergencies. Or, maybe, we keep an eye on the commits since the last release somehow (104ish for 24.x, 26 for 21.x and 36 for 18.x)? To discuss - i suppose we should at least try and release the minor ones when we do a major release... Let's see if we can schedule a release party soon! jonny > On 12 Aug 2022, at 17:26, Roberto Kirschbaum <[email protected]> wrote: > > Hi Jonny, > > I agree major releases every 6 months were exhausting 😉 > > Now, as to formalising the minor updates,I haven't given it much thought, but one first question I have is, what will happen when there's an unexpected critical security bug and fix and the immediate need for release? Will the process face that as a trigger? > > thanks > Roberto > > On Fri, Aug 12, 2022 at 8:03 AM Jonny Bradley via TikiWiki-devel <[email protected]> wrote: >> Thanks Marc >> >> I agree, i think it's about right now - major releases every 6 months was just exhausting! >> >> We do need to release new version of 18.x (Jan 2021) and 21.x (Nov 2021) though, it's been far too long. Maybe we need a more formalised process for releasing minor updates? Roberto, what do you think? >> >> jonny >> >> >> >> > On 11 Aug 2022, at 19:23, Marc Laporte <[email protected]> wrote: >> > >> > Dear Tiki community, >> > >> > 4 years ago, I wrote a summary of our decision at a TikiFest: >> > https://tiki.org/forumthread69969-A-large-majority-of-the-TikiFesters-want-to-move-to-a-3x8-month-lifecycle >> > >> > Here is our process in great detail: https://tiki.org/Versions >> > >> > I think it's optimal, and we should just continue like this for the foreseeable future. >> > >> > As of now, >> > * 18x and 21x are security-fixes only >> > * 24x is bug fixes and minor, self-contained enhancements >> > * trunk (future 25x) is for major developments >> > >> > For those that may have concerns that older LTS versions take away a lot of energy from developers that could be used for building the future: As we can see in commit logs, development on older versions naturally slows down. Any activity in old branches was either important (ex.: MySQL 8 support, security, etc.) or with no risk of regression. >> > https://gitlab.com/tikiwiki/tiki/-/commits/21.x >> > https://gitlab.com/tikiwiki/tiki/-/commits/18.x >> > >> > So I consider our process as "optimal" and can't think of a way to improve it. Any changes would improve some aspects but would have drawbacks. >> > >> > Best regards, >> > >> > Marc >> > >> > >> > _______________________________________________ >> > TikiWiki-devel mailing list >> > [email protected] >> > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel >> >> >> >> _______________________________________________ >> TikiWiki-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > _______________________________________________ TikiWiki-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel