On 4/11/19 4:54 PM, Gerald Combs wrote:
> We currently have three active release branches: 3.0, 2.6, and 2.4. This is 
> because we support each release branch for a set amount of time (typically 24 
> months after the initial .0 release) and our last three .0 releases were less 
> than 12 months apart. However, having many active branches can sometimes 
> cause confusion[1] and far fewer people download the "Old Old Stable" release 
> than the "Old Stable" or "Stable" releases. Would it make sense to have only 
> two release branches active at any given time, e.g. by adjusting our release 
> branch lifetimes to "24 months or whenever we have two newer active branches, 
> whichever comes first"?

After reading through everyone's responses I think it would make sense to 
change my release lifecycle proposal from "24 months or whenever we have two 
newer active branches, whichever comes first" to "18 months or whenever version 
X.Y+4 is released, whichever comes *second*". Specifically, the new lifecycle 
rules would be:

* At least two (and preferably exactly two) branches will be supported at any 
given time.

* Starting with 3.0, each release will be supported for a minimum of 18 months. 
After 18 months, support ends if this is the "Old Old Stable" branch.

* Releases preceding a major change will be supported for a longer period of 
time, e.g. 30 months.

As shown in the diagram, below, 3.0 will have guaranteed support for 18 months 
and support will end when 3.4 is released. Similarly, support for 3.2 will end 
when 3.4 is released.

│ Jan     2019     Dec ││ Jan     2020     Dec ││ Jan     2021     Dec │
─ 2.4 ──────┤
────────── 2.6 ───────────────────────────┤
    ├────────────── 3.0 ───────────────┤┈┈┈[1]
                    ├────────────── 3.2 ───────────────┤┈┈[2]
                                           ├────────────── 3.4 ─────────
                                                          ├─────── 3.6 ─

[1] Support for 3.0 ends when 3.4 is released.
[2] Support for 3.2 ends when 3.6 is released.


> We've also been using odd minor numbers for development releases and even 
> minor numbers for stable releases[2] for many years now. We don't make very 
> many development releases and instead tend to have one or more release 
> candidates after branch is created. Would it make sense to drop the even/odd 
> scheme and make the next major release 3.1.0?

Most people preferred sticking with the current odd = development, even = 
stable release versioning. I'm OK with that.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Reply via email to