Re: [Wireshark-dev] Release lifetime and version number changes?
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 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
Re: [Wireshark-dev] Release lifetime and version number changes?
@Jaap Every build is released to the public like 3.5, 3.6, 3.7, etc. Current stable is 3.7 and development version is 3.8. Based on the docs ( https://docs.python.org/3.8/), the dev branch is alpha stage as it version 3.8.0a3. Once it becomes stable, 3.9 will become the developing version. On Fri, Apr 19, 2019 at 10:19 PM Jaap Keuter wrote: > Does Python release *every* build to the general public, as Wireshark > does? If so, how are these identified? I could only find specific defined > releases, starting from Alpha so-and-so. > > On 12 Apr 2019, at 12:51, Ross Jacobs wrote: > > I agree that even/odd is non-standard and confusing. > > > > I’m not sure. How would we label the development branch? It’s currently > 3.1.0 or is it 3.1.0rc0? (Version 3.1.0 (v3.1.0rc0-521-gdba02458)) would > people understand? > > > But I’m ok either way. > > I think the Python developer guide <https://devguide.python.org/devcycle/> > does > this well: > > > 3.1.0TN : > * T = [a, b, rc] (alpha, beta, release candidate) > * N = release number > > When development would be released, remove TN for release and increment > the MINOR for development branch. > > Cheers, > Ross > > On Fri, Apr 12, 2019 at 8:30 AM Anders Broman > wrote: > >> >> >> >> >> *From:* Wireshark-dev *On Behalf >> Of *graham.shanks via Wireshark-dev >> *Sent:* den 12 april 2019 09:04 >> *To:* Developer support list for Wireshark >> *Cc:* graham.shanks >> *Subject:* Re: [Wireshark-dev] Release lifetime and version number >> changes? >> >> >> >> >I think dropping the even/odd scheme is a good idea. >> >> I’m not sure. How would we label the development branch? It’s currently >> 3.1.0 or is it 3.1.0rc0? (Version 3.1.0 (v3.1.0rc0-521-gdba02458)) would >> people understand? >> >> But I’m ok either way. >> >> >> >> >Personally I'd go down to 2 active branches but then my group wouldn't >> be adversely affected by dropping the "old old stable" version since we >> invariably use the stable version. More weight should be given to the >> opinions of people who do >use old stable versions. I would point out >> that the proposed change gives no firm guarantee on the supported lifetime >> of a branch at all. Could it be as short as two months? Potentially, >> since there would be nothing to stop us releasing a branch >a month >> (unlikely, but from the user's perspective they would have no control over >> that) >> >> >> >> For me 2 active branches sounds good. We use the development branch any >> way with our own ID marking. >> >> Regards >> >> Anders >> >> >> > > ___ > Sent via:Wireshark-dev mailing list > 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 ___ Sent via:Wireshark-dev mailing list 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
Re: [Wireshark-dev] Release lifetime and version number changes?
+1 for having only two supported stable versions. One as a „long term support“ branch (e.g. 2.6 at the moment) and one „normal“ stable (eg. 3.0 atm or next 3.2) +1 for keeping odd minor numbers for development versions. Maybe having a monthly rolling release with latests features to have more test users would make sense. Cheers Uli > Am 12.04.2019 um 01:54 schrieb Gerald Combs : > > 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"? > > 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? > > [1] > https://ask.wireshark.org/question/8433/why-are-multiple-versions-released-at-once/ > [2] https://wiki.wireshark.org/Development/ReleaseNumbers > ___ > Sent via:Wireshark-dev mailing list > 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 ___ Sent via:Wireshark-dev mailing list 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
Re: [Wireshark-dev] Release lifetime and version number changes?
Does Python release *every* build to the general public, as Wireshark does? If so, how are these identified? I could only find specific defined releases, starting from Alpha so-and-so. > On 12 Apr 2019, at 12:51, Ross Jacobs wrote: > > I agree that even/odd is non-standard and confusing. > > > > > I’m not sure. How would we label the development branch? It’s currently > > 3.1.0 or is it 3.1.0rc0? (Version 3.1.0 (v3.1.0rc0-521-gdba02458)) would > > people understand? > > > But I’m ok either way. > > I think the Python developer guide <https://devguide.python.org/devcycle/> > does this well: > > > > 3.1.0TN : > > * T = [a, b, rc] (alpha, beta, release candidate) > * N = release number > > When development would be released, remove TN for release and increment the > MINOR for development branch. > > Cheers, > Ross > > On Fri, Apr 12, 2019 at 8:30 AM Anders Broman <mailto:anders.bro...@ericsson.com>> wrote: > > > > > From: Wireshark-dev <mailto:wireshark-dev-boun...@wireshark.org>> On Behalf Of graham.shanks via > Wireshark-dev > Sent: den 12 april 2019 09:04 > To: Developer support list for Wireshark <mailto:wireshark-dev@wireshark.org>> > Cc: graham.shanks <mailto:graham.sha...@blueyonder.co.uk>> > Subject: Re: [Wireshark-dev] Release lifetime and version number changes? > > > > >I think dropping the even/odd scheme is a good idea. > > I’m not sure. How would we label the development branch? It’s currently 3.1.0 > or is it 3.1.0rc0? (Version 3.1.0 (v3.1.0rc0-521-gdba02458)) would people > understand? > > But I’m ok either way. > > > > >Personally I'd go down to 2 active branches but then my group wouldn't be > >adversely affected by dropping the "old old stable" version since we > >invariably use the stable version. More weight should be given to the > >opinions of people who do >use old stable versions. I would point out that > >the proposed change gives no firm guarantee on the supported lifetime of a > >branch at all. Could it be as short as two months? Potentially, since there > >would be nothing to stop us releasing a branch >a month (unlikely, but from > >the user's perspective they would have no control over that) > > > > For me 2 active branches sounds good. We use the development branch any way > with our own ID marking. > > Regards > > Anders > > > ___ Sent via:Wireshark-dev mailing list 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
Re: [Wireshark-dev] Release lifetime and version number changes?
On Thu, Apr 11, 2019 at 6:55 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"? > > 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? > As others have said, that should be OK as long as the version in the not-released-yet code is identifiable. IIRC part of what got us into odd/even was: https://www.wireshark.org/lists/wireshark-bugs/200712/msg00068.html (Basically: the master branch's version was 0.99.7 while that version was in development. sunfreeware.com couldn't get the prior release to build so they built from SVN and released the software that called itself 0.99.7 - before we released it.) ___ Sent via:Wireshark-dev mailing list 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
Re: [Wireshark-dev] Release lifetime and version number changes?
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 : > 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 < > johnthac...@gmail.com>: > >> >> On Thu, Apr 11, 2019 at 7:55 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"? >>> >> >> 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 >> 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 > > ___ Sent via:Wireshark-dev mailing list 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
Re: [Wireshark-dev] Release lifetime and version number changes?
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 < johnthac...@gmail.com>: > > On Thu, Apr 11, 2019 at 7:55 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"? >> > > 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 > 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 ___ Sent via:Wireshark-dev mailing list 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
Re: [Wireshark-dev] Release lifetime and version number changes?
On Thu, Apr 11, 2019 at 7:55 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"? > 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 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
Re: [Wireshark-dev] Release lifetime and version number changes?
On Fri, 12 Apr 2019 at 00:55, 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"? > Happy with that. > > 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? > I don't see any need to change that unless it makes the release process easier. I think I agree with Ander's comment, what would the value be in the master branch(es) if we changed this? > > [1] > https://ask.wireshark.org/question/8433/why-are-multiple-versions-released-at-once/ > [2] https://wiki.wireshark.org/Development/ReleaseNumbers > -- Graham Bloice ___ Sent via:Wireshark-dev mailing list 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
Re: [Wireshark-dev] Release lifetime and version number changes?
I agree that even/odd is non-standard and confusing. > I’m not sure. How would we label the development branch? It’s currently 3.1.0 or is it 3.1.0rc0? (Version 3.1.0 (v3.1.0rc0-521-gdba02458)) would people understand? > But I’m ok either way. I think the Python developer guide <https://devguide.python.org/devcycle/> does this well: 3.1.0TN : * T = [a, b, rc] (alpha, beta, release candidate) * N = release number When development would be released, remove TN for release and increment the MINOR for development branch. Cheers, Ross On Fri, Apr 12, 2019 at 8:30 AM Anders Broman wrote: > > > > > *From:* Wireshark-dev *On Behalf Of > *graham.shanks via Wireshark-dev > *Sent:* den 12 april 2019 09:04 > *To:* Developer support list for Wireshark > *Cc:* graham.shanks > *Subject:* Re: [Wireshark-dev] Release lifetime and version number > changes? > > > > >I think dropping the even/odd scheme is a good idea. > > I’m not sure. How would we label the development branch? It’s currently > 3.1.0 or is it 3.1.0rc0? (Version 3.1.0 (v3.1.0rc0-521-gdba02458)) would > people understand? > > But I’m ok either way. > > > > >Personally I'd go down to 2 active branches but then my group wouldn't be > adversely affected by dropping the "old old stable" version since we > invariably use the stable version. More weight should be given to the > opinions of people who do >use old stable versions. I would point out > that the proposed change gives no firm guarantee on the supported lifetime > of a branch at all. Could it be as short as two months? Potentially, > since there would be nothing to stop us releasing a branch >a month > (unlikely, but from the user's perspective they would have no control over > that) > > > > For me 2 active branches sounds good. We use the development branch any > way with our own ID marking. > > Regards > > Anders > > > > > > Sent from Samsung tablet. > ___ > Sent via:Wireshark-dev mailing list > 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 ___ Sent via:Wireshark-dev mailing list 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
Re: [Wireshark-dev] Release lifetime and version number changes?
From: Wireshark-dev On Behalf Of graham.shanks via Wireshark-dev Sent: den 12 april 2019 09:04 To: Developer support list for Wireshark Cc: graham.shanks Subject: Re: [Wireshark-dev] Release lifetime and version number changes? >I think dropping the even/odd scheme is a good idea. I’m not sure. How would we label the development branch? It’s currently 3.1.0 or is it 3.1.0rc0? (Version 3.1.0 (v3.1.0rc0-521-gdba02458)) would people understand? But I’m ok either way. >Personally I'd go down to 2 active branches but then my group wouldn't be >adversely affected by dropping the "old old stable" version since we >invariably use the stable version. More weight should be given to the opinions >of people who do >use old stable versions. I would point out that the proposed >change gives no firm guarantee on the supported lifetime of a branch at all. >Could it be as short as two months? Potentially, since there would be nothing >to stop us releasing a branch >a month (unlikely, but from the user's >perspective they would have no control over that) For me 2 active branches sounds good. We use the development branch any way with our own ID marking. Regards Anders Sent from Samsung tablet. smime.p7s Description: S/MIME cryptographic signature ___ Sent via:Wireshark-dev mailing list 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
Re: [Wireshark-dev] Release lifetime and version number changes?
I think dropping the even/odd scheme is a good idea.Personally I'd go down to 2 active branches but then my group wouldn't be adversely affected by dropping the "old old stable" version since we invariably use the stable version. More weight should be given to the opinions of people who do use old stable versions. I would point out that the proposed change gives no firm guarantee on the supported lifetime of a branch at all. Could it be as short as two months? Potentially, since there would be nothing to stop us releasing a branch a month (unlikely, but from the user's perspective they would have no control over that)Sent from Samsung tablet. null___ Sent via:Wireshark-dev mailing list 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
[Wireshark-dev] Release lifetime and version number changes?
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"? 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? [1] https://ask.wireshark.org/question/8433/why-are-multiple-versions-released-at-once/ [2] https://wiki.wireshark.org/Development/ReleaseNumbers ___ Sent via:Wireshark-dev mailing list 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
