[nvda-addons] Re: Request for comments: using year.month scheme for future add-on releases for my add-ons
- From: "Joseph Lee" <joseph.lee22590@xxxxxxxxx>
- To: <nvda-addons@xxxxxxxxxxxxx>
- Date: Thu, 28 Jul 2016 10:37:41 -0700
Hi James,
As for other authors adopting this scheme: I expect not.
As for the bigger picture: you are right in that we do need to worry about
add-on update facility. The reason why I brought this up was to gather feedback
from folks, especially users, as they are seeing two versioning schemes at
work: major.minor and year.month, and wanted to ask if it's better to unify
under a common scheme for add-ons I maintain.
Cheers,
Joseph
-----Original Message-----
From: nvda-addons-bounce@xxxxxxxxxxxxx
[mailto:nvda-addons-bounce@xxxxxxxxxxxxx] On Behalf Of James Scholes
Sent: Thursday, July 28, 2016 10:31 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
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
----------------------------------------------------------------
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:
