Hi,
You could even go as far as day.
Jim
==========
Jim Homme,
Accessibility Consultant,
Bender HighTest Accessibility Team
Bender Consulting Services, Inc.,
412-787-8567,
jhomme@xxxxxxxxxxxxxxxxx
http://www.benderconsult.com/our%20services/hightest-accessible-technology-solutions
E+R=O
-----Original Message-----
From: nvda-addons-bounce@xxxxxxxxxxxxx
[mailto:nvda-addons-bounce@xxxxxxxxxxxxx] On Behalf Of Joseph Lee
Sent: Thursday, July 28, 2016 12:15 PM
To: nvda-addons@xxxxxxxxxxxxx
Subject: [nvda-addons] Re: Request for comments: using year.month scheme for
future add-on releases for my add-ons
Hi,
For fixes released in the same month: this can be designated as
year.month.revision.
Cheers,
Joseph
-----Original Message-----
From: nvda-addons-bounce@xxxxxxxxxxxxx
[mailto:nvda-addons-bounce@xxxxxxxxxxxxx] On Behalf Of Noelia
Sent: Thursday, July 28, 2016 9:03 AM
To: nvda-addons@xxxxxxxxxxxxx
Subject: [nvda-addons] Re: Request for comments: using year.month scheme for
future add-on releases for my add-ons
Hi, I'm not a user of these add-ons, but here is feed-back:
- Advantages: It's easy to know the date.
- Disadvantages:
* The scheme date is not common to everyone, as maybe differences in practices
depending on languages. For instance, in Spanish dates are commonly reported as
day, month, year.
- The version is longer and so it can be more difficult to mention or remember.
- If a minor release fixing an issue is done in the same month and year, it's
not a standarized way to post different versions.
Cheers.
El 28/07/2016 a las 17:44, Jim Homme escribió:
Hi,----------------------------------------------------------------
I think this is great because it is very clear.
Jim
==========
Jim Homme,
Accessibility Consultant,
Bender HighTest Accessibility Team
Bender Consulting Services, Inc.,
412-787-8567,
jhomme@xxxxxxxxxxxxxxxxx
http://www.benderconsult.com/our%20services/hightest-accessible-techno
logy-solutions
E+R=O
*From:* nvda-addons-bounce@xxxxxxxxxxxxx
[mailto:nvda-addons-bounce@xxxxxxxxxxxxx] *On Behalf Of *Joseph Lee
*Sent:* Thursday, July 28, 2016 11:44 AM
*To:* nvda-spl@xxxxxxxxx
*Subject:* [nvda-addons] Request for comments: using year.month scheme
for future add-on releases for my add-ons
Hi everyone,
For the past few years, I used major.minor versioning scheme for my
add-ons except Windows 10 App Essentials. The major number was
incremented whenever a version with new features was released, with
minor version denoting minor enhancements, fixes and translation
updates. Although it worked out well, it led to an issue where people
found out they were using old releases (also caused by lack of add-on
update facility).
To make it easier for people to find out which add-on version they are
using, to make add-on versions uniform across add-ons and to make new
features available in a predictable manner (via time-based releases),
I'm thinking about migrating add-on versioning scheme for my add-ons
to follow year.month designations (for example, GoldWave 16.08). This
would allow users to easily find out which version of the add-on they
are using so they can compare against latest version out there, and
for me to release new versions upon request and on a timely manner. It
also helps in eliminating major.x maintenance branches so maintenance
can be performed from master/stable branches (an exception is for
add-ons that have long-term support (LTS) branches such as SPL Studio).
Comments from users of the following add-ons are requested:
· Control Usage Assistant
· Easy Table Navigator
· Enhanced Touch Gestures
· GoldWave
· Resource Monitor
· StationPlaylist Studio
· Windows 10 App Essentials
Comments from others in the community are also welcome. Thanks.
Cheers,
Joseph
