Version naming suggestion

[dinkypumpkin]

On 10/10/2011 01:25, Nigel Taylor wrote:
> There are only two changes to the get_iplayer script, since v2.80 was
> tagged in git. The other 4 changes are specific to windows, related to
> the windows installer. The need for a v2.81 yet may be open to debate.

As to whether a v2.81 release is justified now, it depends on whether 
you think taggingrelated fixes are important enough to justify it.  As 
it stands now with v2.80, only M4A tagging is broken, for a small 
minority of radio programmes, and in some cases only on Windows. Patches 
have been committed to address those issues, but my view is that doesn't 
yet justify a new release only 6 weeks on from v2.80.  Besides, I'm 
about to push an upgrade to Windows AtomicParsley, so there may be some 
more dust to settle.  I would say wait at least another 6 weeks and 
reconsider.

> In the past the windows installer has held back the releases of a new
> versions of get_iplayer. Timely releases replaces any need to invent new
> version schemes, or end users using other than the released versions.

I agree that timely releases are desirable, but 2 questions arise:

1. How often (if ever) to make regular releases?  I would say every 6 
months at least and every 3 months at most, given the current pace of 
development.

2. What conditions should prompt an unscheduled release?  I think there 
are at least 2 reasons to put out a release between the scheduled releases:

a. Add/restore access to a BBC channel or service
b. Enable a helper application update required by BBC changes

Consider the 2.79->2.80 interregnum.  There were 3 changes which I 
believe met those criteria:

- BBC 7 -> Radio 4 Extra rebranding
- M4A generation from AAC radio streams
- Update to SWF player URL for verification

Those are conditions which will occur very infrequently.  To me, that's 
all the more the reason to commit to a regular release cycle so that 
other patches make it out the door.  Of course, somebody still has to 
poll the mailing list to make sure issues are resolved and patches 
submitted and then enlist David W or his nominee to do the necessaries. 
  Releases aren't terribly time-consuming, but there is a bit of overhead.

> Releases should be made regardless of the windows installer, then should

Let me put this matter to rest.  The release of get_iplayer v2.80 was 
tied to the release of the new Windows installer only because the old 
installer contained hard-coded paths to the various dependency 
downloads.  Thus there was no uniform means for Windows users to get the 
helper apps necessary to work with the v2.80 changes to get_iplayer. 
This should never happen again since the installer can now update helper 
apps independently.

> windows fall behind and window users have to resort to getting the
> get_iplayer script. The version would have been updated for release to
> other platforms allowing identification by version number.

Ideally, we would mostly avoid this with more timely releases. The 
Windows installer is capable of updating the get_iplayer script when a 
new version is available.  There will be some who want or need 
particular patches, but the manual update process is simple enought to 
accommodate those users.