[nvda-addons] Re: Request for comments: using year.month scheme for future add-on releases for my add-ons

  • From: James Scholes <james@xxxxxxxxxxxxx>
  • To: nvda-addons@xxxxxxxxxxxxx
  • Date: Thu, 28 Jul 2016 18:30:56 +0100

Joseph Lee wrote:

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

I don't get it.  It's easy for a user to figure out which version of
your add-on they're running by looking in the Manage add-ons dialog,
this wouldn't change anything in that department.

In terms of people working out whether they're running the latest
version though, I'm struggling to understand how this would create an
improved understanding.  Imagine, a user checks in the Manage add-ons
dialog, and finds out that they're running version 2016.08 of GoldWave,
but it's now December 2016.  So, by rights, they should be running
2016.12.  So, they head over to the add-ons website, only to discover
that actually, you haven't needed to update the GoldWave add-on since
August, so they were running the latest version anyway.  Nothing's
changed, the 2016.08 version number only resulted in a greater amount of
curiosity about whether they had the latest version or not.

However, the main problem I see with this approach is that, rightly or
wrongly, some users will associate the version numbering scheme of your
add-ons with that of NVDA core.  I know, and most people on this list
know, that NVDA doesn't use year.month release identifiers, but users
are users and they won't take that into consideration.

So, to sum up, I just don't see the point.  Version your add-ons how you
want, but are you suggesting this be adopted across all add-ons?
Because I think developers should be able to decide to label their
versions however they feel is appropriate.  I also think we should just
be putting more effort into an add-on updater, rather than debating
small-time semantics.
-- 
James Scholes
http://twitter.com/JamesScholes
----------------------------------------------------------------
NVDA add-ons: A list to discuss add-on code enhancements and for reporting 
bugs. 

Community addons are available from: http://addons.nvda-project.org
To send a message to the list: nvda-addons@xxxxxxxxxxxxx
To change your list settings/unsubscribe: 
//www.freelists.org/list/nvda-addons
To contact list moderators: nvda-addons-moderators@xxxxxxxxxxxxx

Other related posts: