Topics

Developer toolkit, font information, and version numbers


Andy B.
 

Hi,

I am giving everyone an update on Developer toolkit's progress toward a new update. Given no major problems, I will be able to release one sometime tonight or early tomorrow morning. The new version will fix many problems and add new features related to formatting information. The explanation will appear in the release announcement.
In other news, I am considering the possibility of changing the versioning scheme Developer toolkit uses. At the moment, the format is year.major.minor, where major is a release with new features, and minor is a release with only bug fixes. This versioning scheme is getting somewhat complicated to maintain because some bugs require new features, and some features introduce new bugs. Then, the cycle repeats itself until the very end (whenever that happens:)). The new versioning scheme would use this format: year.month. An example version is 20.1 for Jan 2020, and 20.2 for Feb 2020. As a result of this, release cycles are limited to once every calendar month, unless someone requires an emergency update. In that case, the version scheme would look like year.month.patch, where patch is the sequential number of releases in a calendar month. For example, 20.1 is the regular monthly release, and 20.1.1 is the first sequential patch distributed in Jan 2020. The release with the new formatting features will have the old versioning scheme. However, I want to leave the versioning scheme idea out for discussion. What do people think of the new versioning idea?


Noelia Ruiz
 

The reasons you give are roboust for me and so I like this scheme, though other are also valid if they are based on reasons and not are arbitrary, I like it
Enviado desde mi iPhone

El 5 ene 2020, a las 19:19, Andy B. <sonfire11@...> escribió:


Hi,

I am giving everyone an update on Developer toolkit's progress toward a new update. Given no major problems, I will be able to release one sometime tonight or early tomorrow morning. The new version will fix many problems and add new features related to formatting information. The explanation will appear in the release announcement.
In other news, I am considering the possibility of changing the versioning scheme Developer toolkit uses. At the moment, the format is year.major.minor, where major is a release with new features, and minor is a release with only bug fixes. This versioning scheme is getting somewhat complicated to maintain because some bugs require new features, and some features introduce new bugs. Then, the cycle repeats itself until the very end (whenever that happens:)). The new versioning scheme would use this format: year.month. An example version is 20.1 for Jan 2020, and 20.2 for Feb 2020. As a result of this, release cycles are limited to once every calendar month, unless someone requires an emergency update. In that case, the version scheme would look like year.month.patch, where patch is the sequential number of releases in a calendar month. For example, 20.1 is the regular monthly release, and 20.1.1 is the first sequential patch distributed in Jan 2020. The release with the new formatting features will have the old versioning scheme. However, I want to leave the versioning scheme idea out for discussion. What do people think of the new versioning idea?


Brian's Mail list account
 

The one thing to be very careful of is if dates are put into documentation remember that some countries put the month first, while others put the day first.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Noelia Ruiz" <nrm1977@...>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Sunday, January 05, 2020 6:38 PM
Subject: Re: [nvda-addons] Developer toolkit, font information, and version numbers


The reasons you give are roboust for me and so I like this scheme, though other are also valid if they are based on reasons and not are arbitrary, I like it
Enviado desde mi iPhone

El 5 ene 2020, a las 19:19, Andy B. <sonfire11@...> escribió:


Hi,

I am giving everyone an update on Developer toolkit's progress toward a new update. Given no major problems, I will be able to release one sometime tonight or early tomorrow morning. The new version will fix many problems and add new features related to formatting information. The explanation will appear in the release announcement.
In other news, I am considering the possibility of changing the versioning scheme Developer toolkit uses. At the moment, the format is year.major.minor, where major is a release with new features, and minor is a release with only bug fixes. This versioning scheme is getting somewhat complicated to maintain because some bugs require new features, and some features introduce new bugs. Then, the cycle repeats itself until the very end (whenever that happens:)). The new versioning scheme would use this format: year.month. An example version is 20.1 for Jan 2020, and 20.2 for Feb 2020. As a result of this, release cycles are limited to once every calendar month, unless someone requires an emergency update. In that case, the version scheme would look like year.month.patch, where patch is the sequential number of releases in a calendar month. For example, 20.1 is the regular monthly release, and 20.1.1 is the first sequential patch distributed in Jan 2020. The release with the new formatting features will have the old versioning scheme. However, I want to leave the versioning scheme idea out for discussion. What do people think of the new versioning idea?


Luke Davis
 

I have always personally preferred semantic versioning (https://semver.org/), and get annoyed when some speech synths read year.major.minor versions as dates (which makes it silly when asking users what version of NVDA they are on, for example, and they don't realize what's happening and write that their on the February 1st, 2019 version of NVDA).

But that said, your scheme doesn't seem unreasonable.

One thing I will point out with it, however, is that it won't sort well as written. If you are looking at a list of versioned files, you will probably end up with something like:

2020.10.2
2020.1.1
2020.11.1
2020.1.3
2020.2.0
2020.9.4

(Which is my output of the Linux sort command run against a list in a very different order).

Whereas if you always use two digits for the month, you get this:

2020.01.1
2020.01.3
2020.02.0
2020.09.4
2020.10.2
2020.11.1

All of which is also true, if you drop the "20" from the front for shorter version strings, as I believe Joseph does.

Luke

On Sun, 5 Jan 2020, Andy B. wrote:

In other news, I am considering the possibility of changing the versioning scheme Developer toolkit uses. At the moment, the format is year.major.minor,
where major is a release with new features, and minor is a release with only bug fixes. This versioning scheme is getting somewhat complicated to maintain
because some bugs require new features, and some features introduce new bugs. Then, the cycle repeats itself until the very end (whenever that happens:)).
The new versioning scheme would use this format: year.month. An example version is 20.1 for Jan 2020, and 20.2 for Feb 2020. As a result of this, release
cycles are limited to once every calendar month, unless someone requires an emergency update. In that case, the version scheme would look like
year.month.patch, where patch is the sequential number of releases in a calendar month. For example, 20.1 is the regular monthly release, and 20.1.1 is the
first sequential patch distributed in Jan 2020. The release with the new formatting features will have the old versioning scheme. However, I want to leave
the versioning scheme idea out for discussion. What do people think of the new versioning idea?


 

Well I personally like the dropbox versioning scheme.

ie version 20, a number like  1or 2 or 3 or 4 indicating if its stable or not and what branch and then a build number.

Then again, we could use the waterfox new versioning scheme.

ie 2019.12, december 2019.

Or we could combine the 2, ie 2019.3.1.30

30 january 2019 release 3 or something could be a bit complex but still.

On 8/01/2020 4:01 pm, Luke Davis wrote:
I have always personally preferred semantic versioning (https://semver.org/), and get annoyed when some speech synths read year.major.minor versions as dates (which makes it silly when asking users what version of NVDA they are on, for example, and they don't realize what's happening and write that their on the February 1st, 2019 version of NVDA).

But that said, your scheme doesn't seem unreasonable.

One thing I will point out with it, however, is that it won't sort well as written. If you are looking at a list of versioned files, you will probably end up with something like:

2020.10.2
2020.1.1
2020.11.1
2020.1.3
2020.2.0
2020.9.4

(Which is my output of the Linux sort command run against a list in a very different order).

Whereas if you always use two digits for the month, you get this:

2020.01.1
2020.01.3
2020.02.0
2020.09.4
2020.10.2
2020.11.1

All of which is also true, if you drop the "20" from the front for shorter version strings, as I believe Joseph does.

Luke


 On Sun, 5 Jan 2020, Andy B. wrote:

In other news, I am considering the possibility of changing the versioning scheme Developer toolkit uses. At the moment, the format is year.major.minor,
where major is a release with new features, and minor is a release with only bug fixes. This versioning scheme is getting somewhat complicated to maintain
because some bugs require new features, and some features introduce new bugs. Then, the cycle repeats itself until the very end (whenever that happens:)).
The new versioning scheme would use this format: year.month. An example version is 20.1 for Jan 2020, and 20.2 for Feb 2020. As a result of this, release
cycles are limited to once every calendar month, unless someone requires an emergency update. In that case, the version scheme would look like
year.month.patch, where patch is the sequential number of releases in a calendar month. For example, 20.1 is the regular monthly release, and 20.1.1 is the
first sequential patch distributed in Jan 2020. The release with the new formatting features will have the old versioning scheme. However, I want to leave
the versioning scheme idea out for discussion. What do people think of the new versioning idea?


 

Now I know this is bucking the trend of a lot of opensource projects, but what is wrong of 1.0,2.4.3 etc, mozilla stayed like that for ages with firefox and still do this with thunderbird.

On 8/01/2020 4:01 pm, Luke Davis wrote:
I have always personally preferred semantic versioning (https://semver.org/), and get annoyed when some speech synths read year.major.minor versions as dates (which makes it silly when asking users what version of NVDA they are on, for example, and they don't realize what's happening and write that their on the February 1st, 2019 version of NVDA).

But that said, your scheme doesn't seem unreasonable.

One thing I will point out with it, however, is that it won't sort well as written. If you are looking at a list of versioned files, you will probably end up with something like:

2020.10.2
2020.1.1
2020.11.1
2020.1.3
2020.2.0
2020.9.4

(Which is my output of the Linux sort command run against a list in a very different order).

Whereas if you always use two digits for the month, you get this:

2020.01.1
2020.01.3
2020.02.0
2020.09.4
2020.10.2
2020.11.1

All of which is also true, if you drop the "20" from the front for shorter version strings, as I believe Joseph does.

Luke


 On Sun, 5 Jan 2020, Andy B. wrote:

In other news, I am considering the possibility of changing the versioning scheme Developer toolkit uses. At the moment, the format is year.major.minor,
where major is a release with new features, and minor is a release with only bug fixes. This versioning scheme is getting somewhat complicated to maintain
because some bugs require new features, and some features introduce new bugs. Then, the cycle repeats itself until the very end (whenever that happens:)).
The new versioning scheme would use this format: year.month. An example version is 20.1 for Jan 2020, and 20.2 for Feb 2020. As a result of this, release
cycles are limited to once every calendar month, unless someone requires an emergency update. In that case, the version scheme would look like
year.month.patch, where patch is the sequential number of releases in a calendar month. For example, 20.1 is the regular monthly release, and 20.1.1 is the
first sequential patch distributed in Jan 2020. The release with the new formatting features will have the old versioning scheme. However, I want to leave
the versioning scheme idea out for discussion. What do people think of the new versioning idea?


Luke Davis
 

On Wed, 8 Jan 2020, Shaun Everiss wrote:

Now I know this is bucking the trend of a lot of opensource projects, but what is wrong of 1.0,2.4.3 etc, mozilla stayed like that for ages with firefox and still do this with thunderbird.
I agree. There are several versioning schemes which use that format, including semantic versioning which I mentioned.
Most of them encode certain information in the version string.
For SemVer, the first number indicates whether the API was changed (a major change that other developers need to consider before upgrading to it), the second number indicates a new feature that doesn't break anything, and the third indicates a bugfix or patch level.

What you describe as the Waterfox scheme, seems to be what Andy wants to do. Or close to it, anyway. This is a form of Calendar Versioning. (https://calver.org)
Something like year.month.patch.
It doesn't really tell you much about changes that were made, but just tells you when (approximately) the release was. Similar to NVDA's version: the version string of year.major.minor, doesn't tell you if there is a breaking change or anything, it mainly gives you a generalized timeframe, and in the case of the minor number: whether there was a bugfix since the last major version, which could have been a bugfix release itself.

To quote the Wikipedia page on Software Versioning:
"When a date is used to denote version, it is generally for marketing purposes, and an actual version number also exists."
Microsoft Windows is probably the most common example for that.

Obviously in my opinion, Calendar Versioning, if it is the only scheme used, is a little wasteful. I.E. it is wasteful to include a number that only tells your users a publication date (within 364 days, anyway), but doesn't say anything about what that version represents. Did we go to a new year because we fixed a typo in the inline documentation of a piece of code? Or did we do it because we switched from Python 2 to Python 3, and broke everything? The year based version schemes don't tell you any of that in the version number.
Unless you track a "real" version number behind the scenes for people who actually care about such details.

But that's just my opinion, and that is worth only the electrons it took to write. Furthermore, I'm not sure any of this really matters for add-ons. No other code depends on them in most cases, and people probably read changelogs. So whatever versioning system someone wants to use, should be fine.
If there were interdependencies, it would matter a lot more and we would all probably have to adopt a single scheme.

Luke