GitHead questions from the uninitiated

[dinkypumpkin]

On 03/12/2014 07:40, Colin Law wrote:
> On 3 December 2014 at 01:58, Alan Milewczyk <alan at soulman1949.com> wrote:
>> On 03/12/2014 01:23, Jeremy Nicoll - ml get_iplayer wrote:
>>> Or, only grab a newer version from git if you've read here that some
>>> just-discovered problem - which you're experiencing - has just been fixed
>>> in
>>> git.
>>>
>> Think I'll invest in a crystal ball! ;-)
>
> For HEAD updates I use the 'if it works for me stick with what I have
> got' approach.  I update when there is a formal release and just pick
> up the head if I have a problem and there are suggestions that it has
> been addressed in git.

Bottom line: Don't use current Git HEAD unless you are prepared to 
encounter new bugs and breaking changes.  I've added a health warning to 
the wiki instructions to make this clear. You should think of current 
Git HEAD as "next version in development" rather than "latest version". 
  There is a double-edged sword here, of course.  More eyes on code in 
development helps to flush out bugs.  But, only users comfortable with 
the risks should use the bleeding edge version of get_iplayer.

There may be occasions when a fix available at GitHub is necessary to 
access certain programmes, but that will only apply to a subset of 
users. If it doesn't apply to you, don't update.  How to know if a fix 
you need is available?  As has already been suggested, read the commit 
log at GitHub. It will be pretty terse, and possibly cryptic to most 
users, but might help.  Also look at the issue tracker, where a similar 
problem may have been reported:

https://github.com/dinkypumpkin/get_iplayer/issues

Issues fixed by a particular commit will usually be noted as such.  Also 
look at the forums:

https://squarepenguin.co.uk/all-forums/

Your problem may have been reported there, and I might have made 
reference to a fix being available.  And of course, search this list:

http://www.mail-archive.com/get_iplayer@lists.infradead.org/

I think I'm going to split new development and maintenance into separate 
branches after the next release (I'll have to stop referring to Git HEAD 
then).  Given how volatile things are, and the number of problems coming 
to light, and the number of changes in the pipeline, it makes sense. 
That also might make it easier to get bug fixes to those who need them. 
  I prefer to avoid frequent formal releases if possible, due to the 
spike in the support burden that occurs when thousands of Windows users 
get access to the update via the installer. It's usually better to 
communicate info re: fixes as needed. I may have to rethink that when 
things go pear-shaped again.