Re: Release lifetime and version number changes?

[Roland Knall <rknall () gmail com>]

minor correction, it should not read "sullify" but pacify. It has been a
long week ....

Am Fr., 12. Apr. 2019 um 15:01 Uhr schrieb Roland Knall <rknall () gmail com>:

> Just my two cents, I like a clear indication, that I am working with a
> development version beyond the obvious changes of text. SO the versioning
> is usually the first thing I look at.
>
> That being said, I could imagine adopting the Python versioning scheme as
> an alternative to the current even/odd numbering.
>
> As for the number of branches - I allways thought, that actively
> maintaining that many branches is more hassle than it's worth. I know it
> happend now due to special circumstances, and I like a clear indication of
> break (aka the main Qt reasoning behing the 2.8<->3.0 switch), but I think
> it presents more confusion then help to the customers and just tends to
> sullify the little nerds in all of us ;-)
>
> kind regards
> Roland
>
> Am Fr., 12. Apr. 2019 um 14:51 Uhr schrieb John Thacker <
> johnthacker () gmail com>:
>
> > On Thu, Apr 11, 2019 at 7:55 PM Gerald Combs <gerald () wireshark org>
> > 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"?
> >
> > I think two active release branches makes sense, but I'm not sure that it
> > always makes sense to have them be the two newest stable releases. When
> > people decide what release to download (or when Linux distributions build a
> > package, since we want to consider not the direct download stats but also
> > what gets bundled with distributions) the primary consideration is the
> > necessary libraries, not the features. Some stable release branches add a
> > lot of Wireshark feature but don't add a lot of library requirements. For
> > example, I think all that 2.6 added over 2.4 was requiring a version of
> > CMake that all distributions still in long term support already had. Since
> > it's difficult to find a system that could install 2.4 that couldn't also
> > install 2.6, it's really not necessary to support 2.6 and 2.4
> > simultaneously (and that would explain the lack of 2.4 downloads.)
> >
> > OTOH, 3.0 bumps a lot of library versions, so if 3.2 (or whatever it's
> > called) is relatively minor in requirements changes (but heavy enough in
> > features to justify a new branch), I could see it making sense to keep 3.2
> > and 2.6 around, and drop 3.0 support first.
> >
> > Cheers,
> > John Thacker
> >
> > ___________________________________________________________________________
> > 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-request () wireshark org
> > ?subject=unsubscribe
___________________________________________________________________________
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-request () wireshark org?subject=unsubscribe