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 < [email protected]>: > > On Thu, Apr 11, 2019 at 7:55 PM Gerald Combs <[email protected]> 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 <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected] > ?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
