Changes between Version 1 and Version 2 of Ticket #5100, comment 14


Ignore:
Timestamp:
2018-09-11T12:37:50Z (6 years ago)
Author:
Francesco Casella

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #5100, comment 14

    v1 v2  
    33Until we prove that we can have a tighter release cycle (since 2016 it took us between 7 and 11 months between two official releases), the requirement is to have some releatively stable release in-between that people can use if they need crucial bug fixes that cannot easily be patched onto maintenance release.
    44
    5 From what I understand (e.g., [https://en.wikipedia.org/wiki/Software_versioning here]), an alpha release is the first step towards the final official release, which is meant for testing and implies a feature freeze (i.e, a branch off master with our github management style), after which only bugfixes are applied. If we tag the 6 July 2018 version of alpha-something, we generate a lot of confusion, because the key feature expected for 1.13.0, replaceable support, is not there and will be added later.
     5From what I understand (e.g., [https://en.wikipedia.org/wiki/Software_versioning here]), an alpha release is the first step towards the final official release, which is meant for testing and implies a feature freeze (i.e, a branch off master with our github management style), after which only bugfixes are applied. If we tag the 6 July 2018 version alpha-something, we generate a lot of confusion, because the key feature expected for 1.13.0, replaceable support, is not there and will be added later.
    66
    77I'm open to any tag that allows to later install alphas and betas on the same channel, but I would avoid using "alpha" to characterize this release. For example, we could have {{{1.13.0-xxxx-dev}}}, where {{{xxxx}}} is a four-digit numerical code corresponding to the specific tagged release, e.g. {{{1.13.0-0895-dev}}} for what we currently call {{{1.13.0-dev-895}}}.