git.net

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

Re: A proposal...


>> 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 don't see how the minor releases would be serviceable for very long
there. If they're not serviceable,
then users have to move up anyway, then you're back at the status quo
with the dot in a different place.

>>> For me including this would poison almost any proposal it is added to.
>>> In the context above: I want to use directives for opt-in of fixes in
>>> a patch release.
>>
>>
>> FWIW, I propose that a directive addition would be a minor bump because
>> directives are part of a configuration "contract" with users - a set of
>> directives that exist in that major.minor. By adding directives in a patch,
>> we break the contract that would state "Any configuration valid in 3.4.x
>> will always be valid in 3.4.x." We can't do that today, but it would be
>> great if we could. Adding directives only in a minor bump provides a clean
>> point at which a known set of directives are valid.

I don't see the value in a backwards compatible configuration
contract, why we would tie our hands like that? Does anyone see this
aspect of an issue if it's orthogonal to new function?