Discussion:
[Audacity-devel] Version Numbering
Mark Young
2017-02-05 21:08:37 UTC
Permalink
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
Peter Sampson
2017-02-05 21:56:16 UTC
Permalink
I think I'm with Mark on this reasoning

Peter.
Post by 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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Mark Young
2017-02-05 22:05:48 UTC
Permalink
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
Post by Peter Sampson
I think I'm with Mark on this reasoning
Peter.
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
<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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2017-02-06 03:35:20 UTC
Permalink
Here was Vaughan's reply a few years ago, which I largely agree
with:
https://sourceforge.net/p/audacity/mailman/message/32658540/



Gale
Post by 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
I think I'm with Mark on this reasoning
Peter.
Post by 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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-02-06 11:19:42 UTC
Permalink
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.
Steve the Fiddle
2017-02-06 12:17:55 UTC
Permalink
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
Post by Peter Sampson
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.
James Crook
2017-02-06 13:32:38 UTC
Permalink
I'm wary of 'grade inflation' but broadly in agreement.
Post by Steve the Fiddle
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.
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
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.
Post by Steve the Fiddle
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.
Steve the Fiddle
2017-02-06 13:49:46 UTC
Permalink
Post by James Crook
I'm wary of 'grade inflation' but broadly in agreement.
Post by Steve the Fiddle
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.
Post by Steve the Fiddle
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
Post by Steve the Fiddle
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)
Post by Steve the Fiddle
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
Post by Steve the Fiddle
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.
Post by Steve the Fiddle
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.
Post by James Crook
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
Post by James Crook
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
Post by James Crook
--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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Peter Sampson
2017-02-06 14:08:36 UTC
Permalink
Post by James Crook
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
Gale Andrews
2017-02-06 14:09:42 UTC
Permalink
Post by James Crook
I'm wary of 'grade inflation'
Yes me too.
Post by James Crook
but broadly in agreement.
[...]
Post by James Crook
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
Gale Andrews
2017-02-06 14:03:49 UTC
Permalink
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
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.
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
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
Post by Peter Sampson
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Steve the Fiddle
2017-02-06 16:01:54 UTC
Permalink
Post by Gale Andrews
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
Post by Gale Andrews
Gale
Post by Steve the Fiddle
I think it's worth considering changing our version numbering system at
some
Post by Steve the Fiddle
point.Moving to the Semantic "major.minor.patch" system could help us.
QA has concerns when it comes to dropping support for a previously
supported
Post by Steve the Fiddle
platform. A some point it becomes impractical to continue supporting
old/obsolete operating systems, but we don't like to abandon users on
those
Post by Steve the Fiddle
platforms without leaving them with a good legacy version. A made up
example
Post by Steve the Fiddle
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)
Post by Steve the Fiddle
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
Post by Steve the Fiddle
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
Post by Steve the Fiddle
that branch for Windows 7 and 8, and release 3.5.0 from the main branch
for
Post by Steve the Fiddle
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
Post by Steve the Fiddle
for a long time. One of the difficulties in making the switch to a
unitary
Post by Steve the Fiddle
format is compatibility with user's existing projects. Careful handling
of
Post by Steve the Fiddle
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
Post by Steve the Fiddle
1.x.x or 2.x.x projects.
Steve
com>
Post by Steve the Fiddle
Post by Peter Sampson
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
Post by Steve the Fiddle
Post by Peter Sampson
agreed to try out - plus also the option of a Dark Audacity dark theme
(possibly)
plus other changes.
Cheers,
Peter.
------------------------------------------------------------
------------------
Post by Steve the Fiddle
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Robert Hänggi
2017-02-06 16:45:31 UTC
Permalink
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
Post by Steve the Fiddle
Post by Gale Andrews
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
Post by Gale Andrews
Gale
Post by Steve the Fiddle
I think it's worth considering changing our version numbering system at
some
Post by Steve the Fiddle
point.Moving to the Semantic "major.minor.patch" system could help us.
QA has concerns when it comes to dropping support for a previously
supported
Post by Steve the Fiddle
platform. A some point it becomes impractical to continue supporting
old/obsolete operating systems, but we don't like to abandon users on
those
Post by Steve the Fiddle
platforms without leaving them with a good legacy version. A made up
example
Post by Steve the Fiddle
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)
Post by Steve the Fiddle
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
Post by Steve the Fiddle
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
Post by Steve the Fiddle
that branch for Windows 7 and 8, and release 3.5.0 from the main branch
for
Post by Steve the Fiddle
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
Post by Steve the Fiddle
for a long time. One of the difficulties in making the switch to a
unitary
Post by Steve the Fiddle
format is compatibility with user's existing projects. Careful handling
of
Post by Steve the Fiddle
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
Post by Steve the Fiddle
1.x.x or 2.x.x projects.
Steve
com>
Post by Steve the Fiddle
Post by Peter Sampson
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
Post by Steve the Fiddle
Post by Peter Sampson
agreed to try out - plus also the option of a Dark Audacity dark theme
(possibly)
plus other changes.
Cheers,
Peter.
------------------------------------------------------------
------------------
Post by Steve the Fiddle
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2017-02-06 17:37:28 UTC
Permalink
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
Post by Robert Hänggi
Apropos version number.
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
Post by Steve the Fiddle
Post by Gale Andrews
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
Post by Gale Andrews
Gale
Post by Steve the Fiddle
I think it's worth considering changing our version numbering system at
some
Post by Steve the Fiddle
point.Moving to the Semantic "major.minor.patch" system could help us.
QA has concerns when it comes to dropping support for a previously
supported
Post by Steve the Fiddle
platform. A some point it becomes impractical to continue supporting
old/obsolete operating systems, but we don't like to abandon users on
those
Post by Steve the Fiddle
platforms without leaving them with a good legacy version. A made up
example
Post by Steve the Fiddle
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)
Post by Steve the Fiddle
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
Post by Steve the Fiddle
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
Post by Steve the Fiddle
that branch for Windows 7 and 8, and release 3.5.0 from the main branch
for
Post by Steve the Fiddle
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
Post by Steve the Fiddle
for a long time. One of the difficulties in making the switch to a
unitary
Post by Steve the Fiddle
format is compatibility with user's existing projects. Careful handling
of
Post by Steve the Fiddle
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
Post by Steve the Fiddle
1.x.x or 2.x.x projects.
Steve
com>
Post by Steve the Fiddle
Post by Peter Sampson
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
Post by Steve the Fiddle
Post by Peter Sampson
agreed to try out - plus also the option of a Dark Audacity dark theme
(possibly)
plus other changes.
Cheers,
Peter.
------------------------------------------------------------
------------------
Post by Steve the Fiddle
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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Robert Hänggi
2017-02-06 22:39:49 UTC
Permalink
Post by Gale Andrews
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
Post by Gale Andrews
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
Post by Robert Hänggi
Apropos version number.
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
Post by Steve the Fiddle
Post by Gale Andrews
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
Post by Gale Andrews
Gale
Post by Steve the Fiddle
I think it's worth considering changing our version numbering system at
some
Post by Steve the Fiddle
point.Moving to the Semantic "major.minor.patch" system could help us.
QA has concerns when it comes to dropping support for a previously
supported
Post by Steve the Fiddle
platform. A some point it becomes impractical to continue supporting
old/obsolete operating systems, but we don't like to abandon users on
those
Post by Steve the Fiddle
platforms without leaving them with a good legacy version. A made up
example
Post by Steve the Fiddle
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)
Post by Steve the Fiddle
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
Post by Steve the Fiddle
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
Post by Steve the Fiddle
that branch for Windows 7 and 8, and release 3.5.0 from the main branch
for
Post by Steve the Fiddle
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
Post by Steve the Fiddle
for a long time. One of the difficulties in making the switch to a
unitary
Post by Steve the Fiddle
format is compatibility with user's existing projects. Careful handling
of
Post by Steve the Fiddle
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
Post by Steve the Fiddle
1.x.x or 2.x.x projects.
Steve
On 6 February 2017 at 11:19, Peter Sampson
com>
Post by Steve the Fiddle
Post by Peter Sampson
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
Post by Steve the Fiddle
Post by Peter Sampson
agreed to try out - plus also the option of a Dark Audacity dark theme
(possibly)
plus other changes.
Cheers,
Peter.
------------------------------------------------------------
------------------
Post by Steve the Fiddle
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale Andrews
2017-02-07 02:19:41 UTC
Permalink
I can't recall seeing it used.


Gale
Post by Robert Hänggi
Post by Gale Andrews
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
Post by Gale Andrews
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
Post by Robert Hänggi
Apropos version number.
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
Post by Steve the Fiddle
Post by Gale Andrews
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
Post by Gale Andrews
Gale
Post by Steve the Fiddle
I think it's worth considering changing our version numbering system at
some
Post by Steve the Fiddle
point.Moving to the Semantic "major.minor.patch" system could help us.
QA has concerns when it comes to dropping support for a previously
supported
Post by Steve the Fiddle
platform. A some point it becomes impractical to continue supporting
old/obsolete operating systems, but we don't like to abandon users on
those
Post by Steve the Fiddle
platforms without leaving them with a good legacy version. A made up
example
Post by Steve the Fiddle
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)
Post by Steve the Fiddle
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
Post by Steve the Fiddle
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
Post by Steve the Fiddle
that branch for Windows 7 and 8, and release 3.5.0 from the main branch
for
Post by Steve the Fiddle
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
Post by Steve the Fiddle
for a long time. One of the difficulties in making the switch to a
unitary
Post by Steve the Fiddle
format is compatibility with user's existing projects. Careful handling
of
Post by Steve the Fiddle
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
Post by Steve the Fiddle
1.x.x or 2.x.x projects.
Steve
On 6 February 2017 at 11:19, Peter Sampson
com>
Post by Steve the Fiddle
Post by Peter Sampson
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
Post by Steve the Fiddle
Post by Peter Sampson
agreed to try out - plus also the option of a Dark Audacity dark theme
(possibly)
plus other changes.
Cheers,
Peter.
------------------------------------------------------------
------------------
Post by Steve the Fiddle
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
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Vaughan Johnson
2017-02-10 07:45:14 UTC
Permalink
Post by Gale Andrews
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
Vaughan Johnson
2017-02-10 07:45:55 UTC
Permalink
typo: meant "there", not "these. -- V
Post by Vaughan Johnson
Post by Gale Andrews
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
Vaughan Johnson
2017-02-10 07:47:58 UTC
Permalink
Post by Gale Andrews
Here was Vaughan's reply a few years ago, which I largely agree
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
Gale Andrews
2017-02-10 19:04:34 UTC
Permalink
Post by Vaughan Johnson
Post by Gale Andrews
Here was Vaughan's reply a few years ago, which I largely agree
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
Post by Vaughan Johnson
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
James Crook
2017-02-10 22:01:52 UTC
Permalink
Post by Gale Andrews
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.
I think it is really important that experimental versions are better
than beta quality. I'm with Gale in finding betas problematic. The
huge danger with betas is that we accept code that crashes and loses
people's work as being OK for a beta. The problem there is the
perpetual beta problem, no developer wants to fix, and the problem that
no one will want to run such 'betas' for real production work - so they
don't actually help any with test and development.

Rather, in my view, experimental should be pretty darned stable. Ideally
people using betas are subscribed, and when we do find a serious bug, we
can inform users e.g. 'New bug discovered - in the experimental
Automatic Volume Control there is a bug where a very loud sound can set
volume to zero, and you lose the rest of the recording...'. That
combination of stable and informing makes it safe for people to use
experimental for production work. Without that, experimental becomes a
synonym for buggy and is no use to us.
Post by Gale Andrews
But I think any experimental version should be part of Audacity unless
there are compelling reasons otherwise.
I think there is a compelling reason for in the experimental category
considering 'auteur' versions, where ONE person takes full
responsibility for what is in their release. It gives a chance for
cohesion in UI choices, personal responsibility for quality and other
plusses. We can argue whether that is so or not elsewhere. If we do
allow genuine 'auteur' versions in the experimental category, then we
will need careful definition of what 'part of Audacity' actually means
in practice. Here is not the place to debate that, but I do point to it
as an issue that would need to be worked out.

--James.
Gale Andrews
2017-02-11 02:40:57 UTC
Permalink
Thanks, James. I agree experimental releases should be fairly
stable. I think they should not distract or delay getting standard
releases out.

It also depends how much tester involvement we want to encourage
between "releases" of experimental versions.

We must expect bugs between such "releases", but "auteur" versions
seem to be presented as somewhat off limits for inter-release feedback.
I know this is partly a good thing, to give the developer some space to
work in, but several months might be too long to go without an available
binary to give feedback on.

Other things to be decided may include:

* to what extent experimental releases overlap with milestone alphas
of HEAD

* whether experimental versions should be focused just on one or two
areas of interest (like a build that pulled in one or two GitHub topic
branches might do)

* how we control or react to "auteur versions" which others might be
encouraged to make available. Those might be very buggy.but could
still rub off on Team if we don't distinguish such from more
"official"
experimental versions.



Gale
Post by James Crook
Post by Gale Andrews
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.
I think it is really important that experimental versions are better
than beta quality. I'm with Gale in finding betas problematic. The
huge danger with betas is that we accept code that crashes and loses
people's work as being OK for a beta. The problem there is the
perpetual beta problem, no developer wants to fix, and the problem that
no one will want to run such 'betas' for real production work - so they
don't actually help any with test and development.
Rather, in my view, experimental should be pretty darned stable. Ideally
people using betas are subscribed, and when we do find a serious bug, we
can inform users e.g. 'New bug discovered - in the experimental
Automatic Volume Control there is a bug where a very loud sound can set
volume to zero, and you lose the rest of the recording...'. That
combination of stable and informing makes it safe for people to use
experimental for production work. Without that, experimental becomes a
synonym for buggy and is no use to us.
Post by Gale Andrews
But I think any experimental version should be part of Audacity unless
there are compelling reasons otherwise.
I think there is a compelling reason for in the experimental category
considering 'auteur' versions, where ONE person takes full
responsibility for what is in their release. It gives a chance for
cohesion in UI choices, personal responsibility for quality and other
plusses. We can argue whether that is so or not elsewhere. If we do
allow genuine 'auteur' versions in the experimental category, then we
will need careful definition of what 'part of Audacity' actually means
in practice. Here is not the place to debate that, but I do point to it
as an issue that would need to be worked out.
--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
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Loading...