Galaxy Release Cycle Length
Hello all, At one of the GCC2013 Birds of a Feather sessions<http://wiki.galaxyproject.org/Events/GCC2013/BoF/PublicGalaxyServers> the group was very clear that they would like to see less frequent releases of Galaxy. We're currently aiming to do a release every 2 months and have been pretty successful at making that target. In the past, we have tried doing releases more often and less often. Is there a sweet spot for the time between releases? Please reply to the group. We are interested in a discussion. Thanks, Dave C -- http://galaxyproject.org/GCC2013 http://galaxyproject.org/ http://getgalaxy.org/ http://usegalaxy.org/ http://wiki.galaxyproject.org/
Hi Dave two months is a good time between releases. Much more important than the release cycle length is fixing identified bugs on the release branch as well. Regards, Hans-Rudolf On 08/20/2013 08:36 PM, Dave Clements wrote:
Hello all,
At one of the GCC2013 Birds of a Feather sessions <http://wiki.galaxyproject.org/Events/GCC2013/BoF/PublicGalaxyServers> the group was very clear that they would like to see less frequent releases of Galaxy. We're currently aiming to do a release every 2 months and have been pretty successful at making that target. In the past, we have tried doing releases more often and less often.
Is there a sweet spot for the time between releases?
Please reply to the group. We are interested in a discussion.
Thanks,
Dave C
-- http://galaxyproject.org/GCC2013 http://galaxyproject.org/ http://getgalaxy.org/ http://usegalaxy.org/ http://wiki.galaxyproject.org/
___________________________________________________________ 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/
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. The alternative to frequent releases are not better tested and documented releases. I think its impossible for the galaxy team to test on all the diverse configurations galaxy is deployed on. Then you really have accumulated many bugs, feedback from users comes in at once creating coordination need for developers going all at once into bugfixing mode for features they have worked on months ago etc… Then the fixes for these bugs also come only with the next release which is still many months away etc…. This makes it necessary to split development into major releases (say once a year) and minor, bugfix, releases (1-2 months after the major) - where is the gain for the users? 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. To give an example, the job_config is now much better than before and its good that I did not have to wait months from its development to deployment at our site. Now small additional features like setting the number of threads dynamically are suggested, and then I would have to wait again many,many months until the next release. Upgrading galaxy was o.k. and while its unfortunate to have to learn new settings and remember the old ones from sometimes not so good (but improving!) documentation, there is no way around it. I think I will now upgrade more often, because it went so well. I like "release early, release often". best, ido On Aug 20, 2013, at 8:36 PM, Dave Clements <clements@galaxyproject.org> wrote:
Hello all,
At one of the GCC2013 Birds of a Feather sessions the group was very clear that they would like to see less frequent releases of Galaxy. We're currently aiming to do a release every 2 months and have been pretty successful at making that target. In the past, we have tried doing releases more often and less often.
Is there a sweet spot for the time between releases?
Please reply to the group. We are interested in a discussion.
Thanks,
Dave C
-- http://galaxyproject.org/GCC2013 http://galaxyproject.org/ http://getgalaxy.org/ http://usegalaxy.org/ http://wiki.galaxyproject.org/ ___________________________________________________________ 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/
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
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/
participants (5)
-
Dave Clements -
Hans-Rudolf Hotz -
Ido Tamir -
Joachim Jacob | VIB | -
Peter Cock