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 <[email protected]>: > 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
