Version Numbering

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Version Numbering

Mark Young
Hi all,

Curious about the version numbering system that Audacity uses.  What are the situations that cause each section of the number to be bumped?

I had assumed (I know!) that Audacity used Semantic Versioning - as per http://semver.org/.  However that cannot be the case as the new version has new functionality so should be 2.2.0 rather than 2.1.3 (a bug fix only release).

It may be there has been a discussion about this perviously, perhaps on a private list.  But I just wondered if it was something that was public knowlege.

Thanks,
Mark

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Peter Sampson-2
I think I'm with Mark on this reasoning

Peter.

On Sun, Feb 5, 2017 at 9:08 PM, Mark Young <[hidden email]> wrote:
Hi all,

Curious about the version numbering system that Audacity uses.  What are the situations that cause each section of the number to be bumped?

I had assumed (I know!) that Audacity used Semantic Versioning - as per http://semver.org/.  However that cannot be the case as the new version has new functionality so should be 2.2.0 rather than 2.1.3 (a bug fix only release).

It may be there has been a discussion about this perviously, perhaps on a private list.  But I just wondered if it was something that was public knowlege.

Thanks,
Mark

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Mark Young

Thanks Peter,

I wasn't meaning my message to be seen as lobbying for one method or another but rather to try and understand what the different sections of the version number represent in terms of an Audacuty release.

Thats said, I would say that using SemVer is a sensible, clearly understood method of versioning: +1 for me.  I suppose it would mean that the "Z" part of X.Y.Z would rarely be updated unless a bugfix verison is released.

Mark


On 05/02/2017 21:56, Peter Sampson wrote:
I think I'm with Mark on this reasoning

Peter.

On Sun, Feb 5, 2017 at 9:08 PM, Mark Young <[hidden email]> wrote:
Hi all,

Curious about the version numbering system that Audacity uses.  What are the situations that cause each section of the number to be bumped?

I had assumed (I know!) that Audacity used Semantic Versioning - as per http://semver.org/.  However that cannot be the case as the new version has new functionality so should be 2.2.0 rather than 2.1.3 (a bug fix only release).

It may be there has been a discussion about this perviously, perhaps on a private list.  But I just wondered if it was something that was public knowlege.

Thanks,
Mark

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Gale
Administrator
Here was Vaughan's reply a few years ago, which I largely agree
with:
https://sourceforge.net/p/audacity/mailman/message/32658540/



Gale


On 5 February 2017 at 22:05, Mark Young <[hidden email]> wrote:

> Thanks Peter,
>
> I wasn't meaning my message to be seen as lobbying for one method or another
> but rather to try and understand what the different sections of the version
> number represent in terms of an Audacuty release.
>
> Thats said, I would say that using SemVer is a sensible, clearly understood
> method of versioning: +1 for me.  I suppose it would mean that the "Z" part
> of X.Y.Z would rarely be updated unless a bugfix verison is released.
>
> Mark
>
>
> On 05/02/2017 21:56, Peter Sampson wrote:
>
> I think I'm with Mark on this reasoning
>
> Peter.
>
> On Sun, Feb 5, 2017 at 9:08 PM, Mark Young <[hidden email]> wrote:
>>
>> Hi all,
>>
>> Curious about the version numbering system that Audacity uses.  What are
>> the situations that cause each section of the number to be bumped?
>>
>> I had assumed (I know!) that Audacity used Semantic Versioning - as per
>> http://semver.org/.  However that cannot be the case as the new version has
>> new functionality so should be 2.2.0 rather than 2.1.3 (a bug fix only
>> release).
>>
>> It may be there has been a discussion about this perviously, perhaps on a
>> private list.  But I just wondered if it was something that was public
>> knowlege.
>>
>> Thanks,
>> Mark
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Peter Sampson-2
We may well want to consider that version numbering is also a powerful
marketing tool - it can be used to show that we are actively developing
and not just in "maintainance mode".

Let us not forget that it has now been over a year since we rreleased
2.1.2 - we do not look very "active" to the outside world.

If we had a Marketing Manager and if I had that role then (as an ex-Marketeer)
I would be pushing for this release to be 2.2.0.

I would also be looking to the subsequent release to be a 3.0 with the
much-changed menu structure (James' from Dark Audacity) as we have already
agreed to try out - plus also the option of a Dark Audacity dark theme (possibly)
plus other changes.

Cheers,
Peter.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Stevethefiddle
I think it's worth considering changing our version numbering system at some point.Moving to the Semantic "major.minor.patch" system could help us.

Example 1 - supported platforms:

QA has concerns when it comes to dropping support for a previously supported platform. A some point it becomes impractical to continue supporting old/obsolete operating systems, but we don't like to abandon users on those platforms without leaving them with a good legacy version. A made up example of how version numbering could help:

If we decide that we need to drop support for Windows 7 and 8 after the release of Audacity 3.4.2, then the next release, would jump to (at least) 3.5.0 (or 4.0.0 if it has major incompatible API changes). If there are problems on Windows 7/8 with Audacity 3.4.2 that we could resolve, then we would not need to stop 3.5.0 development in order to fix the Windows 7/8 problem - we could create a "legacy" branch on GitHub and release 3.4.3 from that branch for Windows 7 and 8, and release 3.5.0 from the main branch for all other platforms.

Example 2 - Unitary Project Format

For QA, a Unitary Project Format has been at or near to top of the wish list for a long time. One of the difficulties in making the switch to a unitary format is compatibility with user's existing projects. Careful handling of version numbers and branches could help lessen this burden by overlapping for a period of time, a 2.x.x branch (current format) with a new 3.x.x branch (unitary project format). Users would have a reasonable period of time to convert old projects to the new format before we drop support for the old format, and 3.x.x need never be burdened with legacy code to support 1.x.x or 2.x.x projects.

Steve

On 6 February 2017 at 11:19, Peter Sampson <[hidden email]> wrote:
We may well want to consider that version numbering is also a powerful
marketing tool - it can be used to show that we are actively developing
and not just in "maintainance mode".

Let us not forget that it has now been over a year since we rreleased
2.1.2 - we do not look very "active" to the outside world.

If we had a Marketing Manager and if I had that role then (as an ex-Marketeer)
I would be pushing for this release to be 2.2.0.

I would also be looking to the subsequent release to be a 3.0 with the
much-changed menu structure (James' from Dark Audacity) as we have already
agreed to try out - plus also the option of a Dark Audacity dark theme (possibly)
plus other changes.

Cheers,
Peter.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

James Crook
I'm wary of 'grade inflation' but broadly in agreement.

On 2/6/2017 12:17 PM, Steve the Fiddle wrote:

> I think it's worth considering changing our version numbering system at
> some point.Moving to the Semantic "major.minor.patch" system could help us.
>
> Example 1 - supported platforms:
>
> QA has concerns when it comes to dropping support for a previously
> supported platform. A some point it becomes impractical to continue
> supporting old/obsolete operating systems, but we don't like to abandon
> users on those platforms without leaving them with a good legacy version. A
> made up example of how version numbering could help:
>
> If we decide that we need to drop support for Windows 7 and 8 after the
> release of Audacity 3.4.2, then the next release, would jump to (at least)
> 3.5.0 (or 4.0.0 if it has major incompatible API changes). If there are
> problems on Windows 7/8 with Audacity 3.4.2 that we could resolve, then we
> would not need to stop 3.5.0 development in order to fix the Windows 7/8
> problem - we could create a "legacy" branch on GitHub and release 3.4.3
> from that branch for Windows 7 and 8, and release 3.5.0 from the main
> branch for all other platforms.
+1.


> Example 2 - Unitary Project Format
>
> For QA, a Unitary Project Format has been at or near to top of the wish
> list for a long time. One of the difficulties in making the switch to a
> unitary format is compatibility with user's existing projects. Careful
> handling of version numbers and branches could help lessen this burden by
> overlapping for a period of time, a 2.x.x branch (current format) with a
> new 3.x.x branch (unitary project format). Users would have a reasonable
> period of time to convert old projects to the new format before we drop
> support for the old format, and 3.x.x need never be burdened with legacy
> code to support 1.x.x or 2.x.x projects.

+1, if we decide to not provide a dual version.

About currently being prepared version:
2.1.3 is more than a patch release, but I think we are far enough into
it to keep it as 2.1.3.


Responding to Peter's comments... if 2.1.4 has the menu rearrangement
and the dark theme from Dark Audacity I would back it being 2.2.0 - but
not 3.0.0.  Inside it's similar to 2.1.3 - too much so to merit a major
version bump.  A major version bump to 3.0.0 would be appropriate if we
support true real time or unitary project, in my opinion.  Either would
entail major project-format additions.

--James.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Stevethefiddle


On 6 February 2017 at 13:32, James Crook <[hidden email]> wrote:
I'm wary of 'grade inflation' but broadly in agreement.

On 2/6/2017 12:17 PM, Steve the Fiddle wrote:
> I think it's worth considering changing our version numbering system at
> some point.Moving to the Semantic "major.minor.patch" system could help us.
>
> Example 1 - supported platforms:
>
> QA has concerns when it comes to dropping support for a previously
> supported platform. A some point it becomes impractical to continue
> supporting old/obsolete operating systems, but we don't like to abandon
> users on those platforms without leaving them with a good legacy version. A
> made up example of how version numbering could help:
>
> If we decide that we need to drop support for Windows 7 and 8 after the
> release of Audacity 3.4.2, then the next release, would jump to (at least)
> 3.5.0 (or 4.0.0 if it has major incompatible API changes). If there are
> problems on Windows 7/8 with Audacity 3.4.2 that we could resolve, then we
> would not need to stop 3.5.0 development in order to fix the Windows 7/8
> problem - we could create a "legacy" branch on GitHub and release 3.4.3
> from that branch for Windows 7 and 8, and release 3.5.0 from the main
> branch for all other platforms.
+1.


> Example 2 - Unitary Project Format
>
> For QA, a Unitary Project Format has been at or near to top of the wish
> list for a long time. One of the difficulties in making the switch to a
> unitary format is compatibility with user's existing projects. Careful
> handling of version numbers and branches could help lessen this burden by
> overlapping for a period of time, a 2.x.x branch (current format) with a
> new 3.x.x branch (unitary project format). Users would have a reasonable
> period of time to convert old projects to the new format before we drop
> support for the old format, and 3.x.x need never be burdened with legacy
> code to support 1.x.x or 2.x.x projects.

+1, if we decide to not provide a dual version.

I agree that a "dual version" could be a good way to go, but careful management of  version numbers and branches allow us to consider alternatives rather than having to maintain old code regardless of the cost. In other words, it's an option.
 

About currently being prepared version:
2.1.3 is more than a patch release, but I think we are far enough into
it to keep it as 2.1.3.

+1
 


Responding to Peter's comments... if 2.1.4 has the menu rearrangement
and the dark theme from Dark Audacity I would back it being 2.2.0 - but
not 3.0.0.  Inside it's similar to 2.1.3 - too much so to merit a major
version bump.  A major version bump to 3.0.0 would be appropriate if we
support true real time or unitary project, in my opinion.  Either would
entail major project-format additions.

+1

Steve
 

--James.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Gale
Administrator
In reply to this post by Stevethefiddle
Those interesting examples seem to suggest releasing multiple
simultaneous versions, and I assume if we were juggling with
dropping support for some version of macOS too, that adds more
number increments.

So perhaps if/when we have more resources than we do now?


Gale


On 6 February 2017 at 12:17, Steve the Fiddle <[hidden email]> wrote:

> I think it's worth considering changing our version numbering system at some
> point.Moving to the Semantic "major.minor.patch" system could help us.
>
> Example 1 - supported platforms:
>
> QA has concerns when it comes to dropping support for a previously supported
> platform. A some point it becomes impractical to continue supporting
> old/obsolete operating systems, but we don't like to abandon users on those
> platforms without leaving them with a good legacy version. A made up example
> of how version numbering could help:
>
> If we decide that we need to drop support for Windows 7 and 8 after the
> release of Audacity 3.4.2, then the next release, would jump to (at least)
> 3.5.0 (or 4.0.0 if it has major incompatible API changes). If there are
> problems on Windows 7/8 with Audacity 3.4.2 that we could resolve, then we
> would not need to stop 3.5.0 development in order to fix the Windows 7/8
> problem - we could create a "legacy" branch on GitHub and release 3.4.3 from
> that branch for Windows 7 and 8, and release 3.5.0 from the main branch for
> all other platforms.
>
> Example 2 - Unitary Project Format
>
> For QA, a Unitary Project Format has been at or near to top of the wish list
> for a long time. One of the difficulties in making the switch to a unitary
> format is compatibility with user's existing projects. Careful handling of
> version numbers and branches could help lessen this burden by overlapping
> for a period of time, a 2.x.x branch (current format) with a new 3.x.x
> branch (unitary project format). Users would have a reasonable period of
> time to convert old projects to the new format before we drop support for
> the old format, and 3.x.x need never be burdened with legacy code to support
> 1.x.x or 2.x.x projects.
>
> Steve
>
>
> On 6 February 2017 at 11:19, Peter Sampson <[hidden email]>
> wrote:
>>
>> We may well want to consider that version numbering is also a powerful
>> marketing tool - it can be used to show that we are actively developing
>> and not just in "maintainance mode".
>>
>> Let us not forget that it has now been over a year since we rreleased
>> 2.1.2 - we do not look very "active" to the outside world.
>>
>> If we had a Marketing Manager and if I had that role then (as an
>> ex-Marketeer)
>> I would be pushing for this release to be 2.2.0.
>>
>> I would also be looking to the subsequent release to be a 3.0 with the
>> much-changed menu structure (James' from Dark Audacity) as we have already
>> agreed to try out - plus also the option of a Dark Audacity dark theme
>> (possibly)
>> plus other changes.
>>
>> Cheers,
>> Peter.
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Peter Sampson-2
In reply to this post by Stevethefiddle


Responding to Peter's comments... if 2.1.4 has the menu rearrangement
and the dark theme from Dark Audacity I would back it being 2.2.0 - but
not 3.0.0.  Inside it's similar to 2.1.3 - too much so to merit a major
version bump.  A major version bump to 3.0.0 would be appropriate if we
support true real time or unitary project, in my opinion.  Either would
entail major project-format additions.

+1

Steve
 


I'll happily buy that bump ;-))

Peter

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Gale
Administrator
In reply to this post by James Crook
On 6 February 2017 at 13:32, James Crook <[hidden email]> wrote:
> I'm wary of 'grade inflation'

Yes me too.

> but broadly in agreement.

[...]
> Responding to Peter's comments... if 2.1.4 has the menu rearrangement
> and the dark theme from Dark Audacity I would back it being 2.2.0 - but
> not 3.0.0.  Inside it's similar to 2.1.3 - too much so to merit a major
> version bump.  A major version bump to 3.0.0 would be appropriate if we
> support true real time or unitary project, in my opinion.  Either would
> entail major project-format additions.

2.2.0 for what would otherwise be 2.1.4 sounds good to me.


Gale

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Stevethefiddle
In reply to this post by Gale


On 6 February 2017 at 14:03, Gale Andrews <[hidden email]> wrote:
Those interesting examples seem to suggest releasing multiple
simultaneous versions, and I assume if we were juggling with
dropping support for some version of macOS too, that adds more
number increments.

So perhaps if/when we have more resources than we do now?

These examples are merely illustrations of possible benefits. Details for how best to manage releases from more than one branch would need to be worked out. Releases from multiple branches would not necessarily be simultaneous - WxWidgets for example do not synchronise releases from 3.0.x and 3.1.x.

In the first example, (dropping support for an OS version), new releases of the older branch would probably be bug fixes only. The release process for this type of "patch" release could probably be much slimmed down / streamlined. In some cases, such a release may simply be one bug fix different from the previous release, but if it's an important bug for the platform that is being dropped, then it would be very beneficial for users on that platform.

Steve



Gale


On 6 February 2017 at 12:17, Steve the Fiddle <[hidden email]> wrote:
> I think it's worth considering changing our version numbering system at some
> point.Moving to the Semantic "major.minor.patch" system could help us.
>
> Example 1 - supported platforms:
>
> QA has concerns when it comes to dropping support for a previously supported
> platform. A some point it becomes impractical to continue supporting
> old/obsolete operating systems, but we don't like to abandon users on those
> platforms without leaving them with a good legacy version. A made up example
> of how version numbering could help:
>
> If we decide that we need to drop support for Windows 7 and 8 after the
> release of Audacity 3.4.2, then the next release, would jump to (at least)
> 3.5.0 (or 4.0.0 if it has major incompatible API changes). If there are
> problems on Windows 7/8 with Audacity 3.4.2 that we could resolve, then we
> would not need to stop 3.5.0 development in order to fix the Windows 7/8
> problem - we could create a "legacy" branch on GitHub and release 3.4.3 from
> that branch for Windows 7 and 8, and release 3.5.0 from the main branch for
> all other platforms.
>
> Example 2 - Unitary Project Format
>
> For QA, a Unitary Project Format has been at or near to top of the wish list
> for a long time. One of the difficulties in making the switch to a unitary
> format is compatibility with user's existing projects. Careful handling of
> version numbers and branches could help lessen this burden by overlapping
> for a period of time, a 2.x.x branch (current format) with a new 3.x.x
> branch (unitary project format). Users would have a reasonable period of
> time to convert old projects to the new format before we drop support for
> the old format, and 3.x.x need never be burdened with legacy code to support
> 1.x.x or 2.x.x projects.
>
> Steve
>
>
> On 6 February 2017 at 11:19, Peter Sampson <[hidden email]>
> wrote:
>>
>> We may well want to consider that version numbering is also a powerful
>> marketing tool - it can be used to show that we are actively developing
>> and not just in "maintainance mode".
>>
>> Let us not forget that it has now been over a year since we rreleased
>> 2.1.2 - we do not look very "active" to the outside world.
>>
>> If we had a Marketing Manager and if I had that role then (as an
>> ex-Marketeer)
>> I would be pushing for this release to be 2.2.0.
>>
>> I would also be looking to the subsequent release to be a 3.0 with the
>> much-changed menu structure (James' from Dark Audacity) as we have already
>> agreed to try out - plus also the option of a Dark Audacity dark theme
>> (possibly)
>> plus other changes.
>>
>> Cheers,
>> Peter.
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Robert Hänggi
Apropos version number.
NVDA reports the following regarding Audacity:

   productVersion: u'2,1,3,0'

That is,  four numbers.
Firefox, for instance has only three.

Not that this would be seen by anyone but me...
Robert

2017-02-06 17:01 GMT+01:00, Steve the Fiddle <[hidden email]>:

> On 6 February 2017 at 14:03, Gale Andrews <[hidden email]> wrote:
>
>> Those interesting examples seem to suggest releasing multiple
>> simultaneous versions, and I assume if we were juggling with
>> dropping support for some version of macOS too, that adds more
>> number increments.
>>
>> So perhaps if/when we have more resources than we do now?
>>
>
> These examples are merely illustrations of possible benefits. Details for
> how best to manage releases from more than one branch would need to be
> worked out. Releases from multiple branches would not necessarily be
> simultaneous - WxWidgets for example do not synchronise releases from 3.0.x
> and 3.1.x.
>
> In the first example, (dropping support for an OS version), new releases of
> the older branch would probably be bug fixes only. The release process for
> this type of "patch" release could probably be much slimmed down /
> streamlined. In some cases, such a release may simply be one bug fix
> different from the previous release, but if it's an important bug for the
> platform that is being dropped, then it would be very beneficial for users
> on that platform.
>
> Steve
>
>
>
>> Gale
>>
>>
>> On 6 February 2017 at 12:17, Steve the Fiddle <[hidden email]>
>> wrote:
>> > I think it's worth considering changing our version numbering system at
>> some
>> > point.Moving to the Semantic "major.minor.patch" system could help us.
>> >
>> > Example 1 - supported platforms:
>> >
>> > QA has concerns when it comes to dropping support for a previously
>> supported
>> > platform. A some point it becomes impractical to continue supporting
>> > old/obsolete operating systems, but we don't like to abandon users on
>> those
>> > platforms without leaving them with a good legacy version. A made up
>> example
>> > of how version numbering could help:
>> >
>> > If we decide that we need to drop support for Windows 7 and 8 after the
>> > release of Audacity 3.4.2, then the next release, would jump to (at
>> least)
>> > 3.5.0 (or 4.0.0 if it has major incompatible API changes). If there are
>> > problems on Windows 7/8 with Audacity 3.4.2 that we could resolve, then
>> we
>> > would not need to stop 3.5.0 development in order to fix the Windows
>> > 7/8
>> > problem - we could create a "legacy" branch on GitHub and release 3.4.3
>> from
>> > that branch for Windows 7 and 8, and release 3.5.0 from the main branch
>> for
>> > all other platforms.
>> >
>> > Example 2 - Unitary Project Format
>> >
>> > For QA, a Unitary Project Format has been at or near to top of the wish
>> list
>> > for a long time. One of the difficulties in making the switch to a
>> unitary
>> > format is compatibility with user's existing projects. Careful handling
>> of
>> > version numbers and branches could help lessen this burden by
>> > overlapping
>> > for a period of time, a 2.x.x branch (current format) with a new 3.x.x
>> > branch (unitary project format). Users would have a reasonable period
>> > of
>> > time to convert old projects to the new format before we drop support
>> > for
>> > the old format, and 3.x.x need never be burdened with legacy code to
>> support
>> > 1.x.x or 2.x.x projects.
>> >
>> > Steve
>> >
>> >
>> > On 6 February 2017 at 11:19, Peter Sampson <petersampsonaudacity@gmail.
>> com>
>> > wrote:
>> >>
>> >> We may well want to consider that version numbering is also a powerful
>> >> marketing tool - it can be used to show that we are actively
>> >> developing
>> >> and not just in "maintainance mode".
>> >>
>> >> Let us not forget that it has now been over a year since we rreleased
>> >> 2.1.2 - we do not look very "active" to the outside world.
>> >>
>> >> If we had a Marketing Manager and if I had that role then (as an
>> >> ex-Marketeer)
>> >> I would be pushing for this release to be 2.2.0.
>> >>
>> >> I would also be looking to the subsequent release to be a 3.0 with the
>> >> much-changed menu structure (James' from Dark Audacity) as we have
>> already
>> >> agreed to try out - plus also the option of a Dark Audacity dark theme
>> >> (possibly)
>> >> plus other changes.
>> >>
>> >> Cheers,
>> >> Peter.
>> >>
>> >
>> > ------------------------------------------------------------
>> ------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > audacity-devel mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>> >
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Gale
Administrator
The fourth number is #define AUDACITY_MODLEVEL  in src/Audacity.h.

Windows and Mac sighted users can see the fourth number in the properties
of the Audacity executable (on Windows, hovering over audacity.exe
shows it in a popup).



Gale


On 6 February 2017 at 16:45, Robert Hänggi <[hidden email]> wrote:

> Apropos version number.
> NVDA reports the following regarding Audacity:
>
>    productVersion: u'2,1,3,0'
>
> That is,  four numbers.
> Firefox, for instance has only three.
>
> Not that this would be seen by anyone but me...
> Robert
>
> 2017-02-06 17:01 GMT+01:00, Steve the Fiddle <[hidden email]>:
>> On 6 February 2017 at 14:03, Gale Andrews <[hidden email]> wrote:
>>
>>> Those interesting examples seem to suggest releasing multiple
>>> simultaneous versions, and I assume if we were juggling with
>>> dropping support for some version of macOS too, that adds more
>>> number increments.
>>>
>>> So perhaps if/when we have more resources than we do now?
>>>
>>
>> These examples are merely illustrations of possible benefits. Details for
>> how best to manage releases from more than one branch would need to be
>> worked out. Releases from multiple branches would not necessarily be
>> simultaneous - WxWidgets for example do not synchronise releases from 3.0.x
>> and 3.1.x.
>>
>> In the first example, (dropping support for an OS version), new releases of
>> the older branch would probably be bug fixes only. The release process for
>> this type of "patch" release could probably be much slimmed down /
>> streamlined. In some cases, such a release may simply be one bug fix
>> different from the previous release, but if it's an important bug for the
>> platform that is being dropped, then it would be very beneficial for users
>> on that platform.
>>
>> Steve
>>
>>
>>
>>> Gale
>>>
>>>
>>> On 6 February 2017 at 12:17, Steve the Fiddle <[hidden email]>
>>> wrote:
>>> > I think it's worth considering changing our version numbering system at
>>> some
>>> > point.Moving to the Semantic "major.minor.patch" system could help us.
>>> >
>>> > Example 1 - supported platforms:
>>> >
>>> > QA has concerns when it comes to dropping support for a previously
>>> supported
>>> > platform. A some point it becomes impractical to continue supporting
>>> > old/obsolete operating systems, but we don't like to abandon users on
>>> those
>>> > platforms without leaving them with a good legacy version. A made up
>>> example
>>> > of how version numbering could help:
>>> >
>>> > If we decide that we need to drop support for Windows 7 and 8 after the
>>> > release of Audacity 3.4.2, then the next release, would jump to (at
>>> least)
>>> > 3.5.0 (or 4.0.0 if it has major incompatible API changes). If there are
>>> > problems on Windows 7/8 with Audacity 3.4.2 that we could resolve, then
>>> we
>>> > would not need to stop 3.5.0 development in order to fix the Windows
>>> > 7/8
>>> > problem - we could create a "legacy" branch on GitHub and release 3.4.3
>>> from
>>> > that branch for Windows 7 and 8, and release 3.5.0 from the main branch
>>> for
>>> > all other platforms.
>>> >
>>> > Example 2 - Unitary Project Format
>>> >
>>> > For QA, a Unitary Project Format has been at or near to top of the wish
>>> list
>>> > for a long time. One of the difficulties in making the switch to a
>>> unitary
>>> > format is compatibility with user's existing projects. Careful handling
>>> of
>>> > version numbers and branches could help lessen this burden by
>>> > overlapping
>>> > for a period of time, a 2.x.x branch (current format) with a new 3.x.x
>>> > branch (unitary project format). Users would have a reasonable period
>>> > of
>>> > time to convert old projects to the new format before we drop support
>>> > for
>>> > the old format, and 3.x.x need never be burdened with legacy code to
>>> support
>>> > 1.x.x or 2.x.x projects.
>>> >
>>> > Steve
>>> >
>>> >
>>> > On 6 February 2017 at 11:19, Peter Sampson <petersampsonaudacity@gmail.
>>> com>
>>> > wrote:
>>> >>
>>> >> We may well want to consider that version numbering is also a powerful
>>> >> marketing tool - it can be used to show that we are actively
>>> >> developing
>>> >> and not just in "maintainance mode".
>>> >>
>>> >> Let us not forget that it has now been over a year since we rreleased
>>> >> 2.1.2 - we do not look very "active" to the outside world.
>>> >>
>>> >> If we had a Marketing Manager and if I had that role then (as an
>>> >> ex-Marketeer)
>>> >> I would be pushing for this release to be 2.2.0.
>>> >>
>>> >> I would also be looking to the subsequent release to be a 3.0 with the
>>> >> much-changed menu structure (James' from Dark Audacity) as we have
>>> already
>>> >> agreed to try out - plus also the option of a Dark Audacity dark theme
>>> >> (possibly)
>>> >> plus other changes.
>>> >>
>>> >> Cheers,
>>> >> Peter.
>>> >>
>>> >
>>> > ------------------------------------------------------------
>>> ------------------
>>> > Check out the vibrant tech community on one of the world's most
>>> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> > _______________________________________________
>>> > audacity-devel mailing list
>>> > [hidden email]
>>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>> >
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Robert Hänggi
2017-02-06 18:37 GMT+01:00, Gale Andrews <[hidden email]>:
> The fourth number is #define AUDACITY_MODLEVEL  in src/Audacity.h.
>
So  what's the meaning of it and on what occasions is it increased?

Robert

> Windows and Mac sighted users can see the fourth number in the properties
> of the Audacity executable (on Windows, hovering over audacity.exe
> shows it in a popup).
>
>
>
> Gale
>
>
> On 6 February 2017 at 16:45, Robert Hänggi <[hidden email]> wrote:
>> Apropos version number.
>> NVDA reports the following regarding Audacity:
>>
>>    productVersion: u'2,1,3,0'
>>
>> That is,  four numbers.
>> Firefox, for instance has only three.
>>
>> Not that this would be seen by anyone but me...
>> Robert
>>
>> 2017-02-06 17:01 GMT+01:00, Steve the Fiddle <[hidden email]>:
>>> On 6 February 2017 at 14:03, Gale Andrews <[hidden email]> wrote:
>>>
>>>> Those interesting examples seem to suggest releasing multiple
>>>> simultaneous versions, and I assume if we were juggling with
>>>> dropping support for some version of macOS too, that adds more
>>>> number increments.
>>>>
>>>> So perhaps if/when we have more resources than we do now?
>>>>
>>>
>>> These examples are merely illustrations of possible benefits. Details for
>>> how best to manage releases from more than one branch would need to be
>>> worked out. Releases from multiple branches would not necessarily be
>>> simultaneous - WxWidgets for example do not synchronise releases from
>>> 3.0.x
>>> and 3.1.x.
>>>
>>> In the first example, (dropping support for an OS version), new releases
>>> of
>>> the older branch would probably be bug fixes only. The release process
>>> for
>>> this type of "patch" release could probably be much slimmed down /
>>> streamlined. In some cases, such a release may simply be one bug fix
>>> different from the previous release, but if it's an important bug for the
>>> platform that is being dropped, then it would be very beneficial for
>>> users
>>> on that platform.
>>>
>>> Steve
>>>
>>>
>>>
>>>> Gale
>>>>
>>>>
>>>> On 6 February 2017 at 12:17, Steve the Fiddle <[hidden email]>
>>>> wrote:
>>>> > I think it's worth considering changing our version numbering system
>>>> > at
>>>> some
>>>> > point.Moving to the Semantic "major.minor.patch" system could help us.
>>>> >
>>>> > Example 1 - supported platforms:
>>>> >
>>>> > QA has concerns when it comes to dropping support for a previously
>>>> supported
>>>> > platform. A some point it becomes impractical to continue supporting
>>>> > old/obsolete operating systems, but we don't like to abandon users on
>>>> those
>>>> > platforms without leaving them with a good legacy version. A made up
>>>> example
>>>> > of how version numbering could help:
>>>> >
>>>> > If we decide that we need to drop support for Windows 7 and 8 after
>>>> > the
>>>> > release of Audacity 3.4.2, then the next release, would jump to (at
>>>> least)
>>>> > 3.5.0 (or 4.0.0 if it has major incompatible API changes). If there
>>>> > are
>>>> > problems on Windows 7/8 with Audacity 3.4.2 that we could resolve,
>>>> > then
>>>> we
>>>> > would not need to stop 3.5.0 development in order to fix the Windows
>>>> > 7/8
>>>> > problem - we could create a "legacy" branch on GitHub and release
>>>> > 3.4.3
>>>> from
>>>> > that branch for Windows 7 and 8, and release 3.5.0 from the main
>>>> > branch
>>>> for
>>>> > all other platforms.
>>>> >
>>>> > Example 2 - Unitary Project Format
>>>> >
>>>> > For QA, a Unitary Project Format has been at or near to top of the
>>>> > wish
>>>> list
>>>> > for a long time. One of the difficulties in making the switch to a
>>>> unitary
>>>> > format is compatibility with user's existing projects. Careful
>>>> > handling
>>>> of
>>>> > version numbers and branches could help lessen this burden by
>>>> > overlapping
>>>> > for a period of time, a 2.x.x branch (current format) with a new 3.x.x
>>>> > branch (unitary project format). Users would have a reasonable period
>>>> > of
>>>> > time to convert old projects to the new format before we drop support
>>>> > for
>>>> > the old format, and 3.x.x need never be burdened with legacy code to
>>>> support
>>>> > 1.x.x or 2.x.x projects.
>>>> >
>>>> > Steve
>>>> >
>>>> >
>>>> > On 6 February 2017 at 11:19, Peter Sampson
>>>> > <petersampsonaudacity@gmail.
>>>> com>
>>>> > wrote:
>>>> >>
>>>> >> We may well want to consider that version numbering is also a
>>>> >> powerful
>>>> >> marketing tool - it can be used to show that we are actively
>>>> >> developing
>>>> >> and not just in "maintainance mode".
>>>> >>
>>>> >> Let us not forget that it has now been over a year since we rreleased
>>>> >> 2.1.2 - we do not look very "active" to the outside world.
>>>> >>
>>>> >> If we had a Marketing Manager and if I had that role then (as an
>>>> >> ex-Marketeer)
>>>> >> I would be pushing for this release to be 2.2.0.
>>>> >>
>>>> >> I would also be looking to the subsequent release to be a 3.0 with
>>>> >> the
>>>> >> much-changed menu structure (James' from Dark Audacity) as we have
>>>> already
>>>> >> agreed to try out - plus also the option of a Dark Audacity dark
>>>> >> theme
>>>> >> (possibly)
>>>> >> plus other changes.
>>>> >>
>>>> >> Cheers,
>>>> >> Peter.
>>>> >>
>>>> >
>>>> > ------------------------------------------------------------
>>>> ------------------
>>>> > Check out the vibrant tech community on one of the world's most
>>>> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> > _______________________________________________
>>>> > audacity-devel mailing list
>>>> > [hidden email]
>>>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>> >
>>>>
>>>> ------------------------------------------------------------
>>>> ------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> audacity-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Gale
Administrator
I can't recall seeing it used.


Gale


On 6 February 2017 at 22:39, Robert Hänggi <[hidden email]> wrote:

> 2017-02-06 18:37 GMT+01:00, Gale Andrews <[hidden email]>:
>> The fourth number is #define AUDACITY_MODLEVEL  in src/Audacity.h.
>>
> So  what's the meaning of it and on what occasions is it increased?
>
> Robert
>> Windows and Mac sighted users can see the fourth number in the properties
>> of the Audacity executable (on Windows, hovering over audacity.exe
>> shows it in a popup).
>>
>>
>>
>> Gale
>>
>>
>> On 6 February 2017 at 16:45, Robert Hänggi <[hidden email]> wrote:
>>> Apropos version number.
>>> NVDA reports the following regarding Audacity:
>>>
>>>    productVersion: u'2,1,3,0'
>>>
>>> That is,  four numbers.
>>> Firefox, for instance has only three.
>>>
>>> Not that this would be seen by anyone but me...
>>> Robert
>>>
>>> 2017-02-06 17:01 GMT+01:00, Steve the Fiddle <[hidden email]>:
>>>> On 6 February 2017 at 14:03, Gale Andrews <[hidden email]> wrote:
>>>>
>>>>> Those interesting examples seem to suggest releasing multiple
>>>>> simultaneous versions, and I assume if we were juggling with
>>>>> dropping support for some version of macOS too, that adds more
>>>>> number increments.
>>>>>
>>>>> So perhaps if/when we have more resources than we do now?
>>>>>
>>>>
>>>> These examples are merely illustrations of possible benefits. Details for
>>>> how best to manage releases from more than one branch would need to be
>>>> worked out. Releases from multiple branches would not necessarily be
>>>> simultaneous - WxWidgets for example do not synchronise releases from
>>>> 3.0.x
>>>> and 3.1.x.
>>>>
>>>> In the first example, (dropping support for an OS version), new releases
>>>> of
>>>> the older branch would probably be bug fixes only. The release process
>>>> for
>>>> this type of "patch" release could probably be much slimmed down /
>>>> streamlined. In some cases, such a release may simply be one bug fix
>>>> different from the previous release, but if it's an important bug for the
>>>> platform that is being dropped, then it would be very beneficial for
>>>> users
>>>> on that platform.
>>>>
>>>> Steve
>>>>
>>>>
>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>> On 6 February 2017 at 12:17, Steve the Fiddle <[hidden email]>
>>>>> wrote:
>>>>> > I think it's worth considering changing our version numbering system
>>>>> > at
>>>>> some
>>>>> > point.Moving to the Semantic "major.minor.patch" system could help us.
>>>>> >
>>>>> > Example 1 - supported platforms:
>>>>> >
>>>>> > QA has concerns when it comes to dropping support for a previously
>>>>> supported
>>>>> > platform. A some point it becomes impractical to continue supporting
>>>>> > old/obsolete operating systems, but we don't like to abandon users on
>>>>> those
>>>>> > platforms without leaving them with a good legacy version. A made up
>>>>> example
>>>>> > of how version numbering could help:
>>>>> >
>>>>> > If we decide that we need to drop support for Windows 7 and 8 after
>>>>> > the
>>>>> > release of Audacity 3.4.2, then the next release, would jump to (at
>>>>> least)
>>>>> > 3.5.0 (or 4.0.0 if it has major incompatible API changes). If there
>>>>> > are
>>>>> > problems on Windows 7/8 with Audacity 3.4.2 that we could resolve,
>>>>> > then
>>>>> we
>>>>> > would not need to stop 3.5.0 development in order to fix the Windows
>>>>> > 7/8
>>>>> > problem - we could create a "legacy" branch on GitHub and release
>>>>> > 3.4.3
>>>>> from
>>>>> > that branch for Windows 7 and 8, and release 3.5.0 from the main
>>>>> > branch
>>>>> for
>>>>> > all other platforms.
>>>>> >
>>>>> > Example 2 - Unitary Project Format
>>>>> >
>>>>> > For QA, a Unitary Project Format has been at or near to top of the
>>>>> > wish
>>>>> list
>>>>> > for a long time. One of the difficulties in making the switch to a
>>>>> unitary
>>>>> > format is compatibility with user's existing projects. Careful
>>>>> > handling
>>>>> of
>>>>> > version numbers and branches could help lessen this burden by
>>>>> > overlapping
>>>>> > for a period of time, a 2.x.x branch (current format) with a new 3.x.x
>>>>> > branch (unitary project format). Users would have a reasonable period
>>>>> > of
>>>>> > time to convert old projects to the new format before we drop support
>>>>> > for
>>>>> > the old format, and 3.x.x need never be burdened with legacy code to
>>>>> support
>>>>> > 1.x.x or 2.x.x projects.
>>>>> >
>>>>> > Steve
>>>>> >
>>>>> >
>>>>> > On 6 February 2017 at 11:19, Peter Sampson
>>>>> > <petersampsonaudacity@gmail.
>>>>> com>
>>>>> > wrote:
>>>>> >>
>>>>> >> We may well want to consider that version numbering is also a
>>>>> >> powerful
>>>>> >> marketing tool - it can be used to show that we are actively
>>>>> >> developing
>>>>> >> and not just in "maintainance mode".
>>>>> >>
>>>>> >> Let us not forget that it has now been over a year since we rreleased
>>>>> >> 2.1.2 - we do not look very "active" to the outside world.
>>>>> >>
>>>>> >> If we had a Marketing Manager and if I had that role then (as an
>>>>> >> ex-Marketeer)
>>>>> >> I would be pushing for this release to be 2.2.0.
>>>>> >>
>>>>> >> I would also be looking to the subsequent release to be a 3.0 with
>>>>> >> the
>>>>> >> much-changed menu structure (James' from Dark Audacity) as we have
>>>>> already
>>>>> >> agreed to try out - plus also the option of a Dark Audacity dark
>>>>> >> theme
>>>>> >> (possibly)
>>>>> >> plus other changes.
>>>>> >>
>>>>> >> Cheers,
>>>>> >> Peter.
>>>>> >>
>>>>> >
>>>>> > ------------------------------------------------------------
>>>>> ------------------
>>>>> > Check out the vibrant tech community on one of the world's most
>>>>> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>> > _______________________________________________
>>>>> > audacity-devel mailing list
>>>>> > [hidden email]
>>>>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>> >
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> audacity-devel mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Vaughan Johnson-4
In reply to this post by Gale
On Mon, Feb 6, 2017 at 9:37 AM, Gale Andrews <[hidden email]> wrote:
> The fourth number is #define AUDACITY_MODLEVEL  in src/Audacity.h.
>
> Windows and Mac sighted users can see the fourth number in the properties
> of the Audacity executable (on Windows, hovering over audacity.exe
> shows it in a popup).
>


Right, and used only because the platforms want something these, and
we don't change it, iirc.

- V

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Vaughan Johnson-4
typo: meant "there", not "these. -- V

On Thu, Feb 9, 2017 at 11:45 PM, Vaughan Johnson <[hidden email]> wrote:

> On Mon, Feb 6, 2017 at 9:37 AM, Gale Andrews <[hidden email]> wrote:
>> The fourth number is #define AUDACITY_MODLEVEL  in src/Audacity.h.
>>
>> Windows and Mac sighted users can see the fourth number in the properties
>> of the Audacity executable (on Windows, hovering over audacity.exe
>> shows it in a popup).
>>
>
>
> Right, and used only because the platforms want something these, and
> we don't change it, iirc.
>
> - V

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Vaughan Johnson-4
In reply to this post by Gale
On Sun, Feb 5, 2017 at 7:35 PM, Gale Andrews <[hidden email]> wrote:
> Here was Vaughan's reply a few years ago, which I largely agree
> with:
> https://sourceforge.net/p/audacity/mailman/message/32658540/
>

Thanks, Gale. In case it's not clear from that, I'm flexible.

But I also think we have varied in how we increment it.  Early years,
we basically did semver .  Several of the 1.3.x versions should have
at least changed to 1.x.y  (e.g., massive restructuring of blockfile
handling that Markus & Monty did).  Then, much later, 2.0.0 and 2.1.0
clearly warranted those designations.  Varying levels of attention to
appropriateness of version number over the years, with shifting groups
of contributors. I'm +1 on at least discussing it each time, during
dev process.

+1 to Peter's comment about showing we're not just in maintenance
mode. (and doing it!)  OTOH, I'm not sure menu and color changes
without new features warrant 3.0 . For sure, a change in the 2nd
position ("minor").  I'm with James (& others) on that, and what would
warrant 3.0 designation.

Steve, good points.  Fwiw, we used to do parallel versions -- with
betas.  But Gale , our sole QA guy at the time, found that
problematic, iirc, so we switched to doing only 'stable' releases.

Re James's comment,  I don't think we need to worry about inflation
when we're only at 2.1.x after 17 years.  :-)

And +1 to James's point -- not renumbering 2.1.3 so late in the process.

Thanks,
Vaughan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Version Numbering

Gale
Administrator
On 10 February 2017 at 07:47, Vaughan Johnson <[hidden email]> wrote:

> On Sun, Feb 5, 2017 at 7:35 PM, Gale Andrews <[hidden email]> wrote:
>> Here was Vaughan's reply a few years ago, which I largely agree
>> with:
>> https://sourceforge.net/p/audacity/mailman/message/32658540/
>>
>
> Thanks, Gale. In case it's not clear from that, I'm flexible.
>
> But I also think we have varied in how we increment it.  Early years,
> we basically did semver .  Several of the 1.3.x versions should have
> at least changed to 1.x.y  (e.g., massive restructuring of blockfile
> handling that Markus & Monty did).  Then, much later, 2.0.0 and 2.1.0
> clearly warranted those designations.  Varying levels of attention to
> appropriateness of version number over the years, with shifting groups
> of contributors. I'm +1 on at least discussing it each time, during
> dev process.
>
> +1 to Peter's comment about showing we're not just in maintenance
> mode. (and doing it!)  OTOH, I'm not sure menu and color changes
> without new features warrant 3.0 . For sure, a change in the 2nd
> position ("minor").  I'm with James (& others) on that, and what would
> warrant 3.0 designation.
>
> Steve, good points.  Fwiw, we used to do parallel versions -- with
> betas.  But Gale , our sole QA guy at the time, found that
> problematic, iirc, so we switched to doing only 'stable' releases.

De facto there wasn't any parallelism because 1.2 which was
representing the "stable" branch did not change for about six years.

I'm mildly in favour in principle of an "experimental version" with
"releases"  that runs alongside 2.x.x. At least, in favour of discussing
it.

But I think any experimental version should be part of Audacity unless
there are compelling reasons otherwise.



Gale


> Re James's comment,  I don't think we need to worry about inflation
> when we're only at 2.1.x after 17 years.  :-)
>
> And +1 to James's point -- not renumbering 2.1.3 so late in the process.
>
> Thanks,
> Vaughan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
12
Loading...