I follow Peter. Shorter release cycles, and I will likely skip updates (as I have done in the past). Longer, and I am starting to implement patches on bitbucket myself to bugs I found, instead of waiting for the next release (which sometimes annoys mercurial - when appropriate I ask for a pull request of course).

So I prefer bimonthly updates.

Cheers
Joachim

Joachim Jacob
Contact details: http://www.bits.vib.be/index.php/about/80-team


On 08/21/2013 10:16 AM, Peter Cock wrote:

On Wednesday, August 21, 2013, Ido Tamir wrote:

    Why the dislike for quick turnover? Could somebody present the
    arguments for people not having been at the BOF?

    People don't have to upgrade - unless its breaking changes that
    e.g. disable the possibility to download from the public toolshed
    which forced me to upgrade.


I personally don't immediately apply the updates to our (perhaps relatively small) Galaxy instance, unless it includes a bug fix I am particularly interested in, or I need it for a new tool I want to install. This is down to my time rather than anything else - as there is always the chance of things breaking, so needs planning accordingly.

So monthly or two-monthly seems about right, but longer than that is frustrating if I am waiting for a fix. Sorter releases just means I will skip more of them, but there is still a time sink reviewing each set of release notes to make this judgement.

    ...
    I would not even split things between breaking changes and minor
    changes. I think this slows down development of the platform and
    what concerns
    people most, the tools, are developed independently of the
    platform and one can upgrade them any time.


Actually as a Tool developer, things are often NOT independent of the Galaxy version - I have had to hold back releases to the Tool Shed because they won't work until a bug fix is released to the stable branch, and then allow some time before we can assume most potential users have the update installed.

(This is another example where real version numbers like major.minor.revision for Galaxy releases would help - along with the related issue of tools being able to specify a minimum version of Galaxy they require)

Peter



___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
   http://lists.bx.psu.edu/

To search Galaxy mailing lists use the unified search at:
   http://galaxyproject.org/search/mailinglists/

___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
 http://lists.bx.psu.edu/

To search Galaxy mailing lists use the unified search at:
 http://galaxyproject.org/search/mailinglists/

Reply via email to