git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A proposal...



Le 24/04/2018 à 19:58, Daniel Ruggeri a écrit :
One thing you mention above is "wait for a new minor release". I can definitely see that being an issue for our current maj.minor layout given that minor bumps are measured in years. In this proposal, unless there's a pressing need to send out a patch release right now, the next version WOULD be that minor bump. Put into practice, I would see major bumps being measured in years, minor bumps in quarters and patch bumps in weeks/months.
I think the same.
But we should be clear on how long we maintain each version and the effort needed for that.

How long does we backport bug fixes?
How long does we fix security issues?
Should we also need some kind of LTS version? If yes, how to choose them? M.0.0 version? In an unpredictable way as Linux does, "when it's time for it"? On a timely basis as Ubuntu does?

2.2 vs 2.4 was already not that active in the last months/years of 2.2, as already discussed in the list. I'm a bit reluctant to backport things in, let say, 4 minors branches because we maintain them for 1 year (4 quarters) + 1 or maybe even 2 LTS branches! To dare to go this way, either me need much more man power (and I'm please to see many names active on the list these days), or we should avoid writing bugs, so we don't have to maintain fix for them :)

CJ