Re: [galaxy-dev] Galaxy Release Cycle Length

[Leon Mei]

Hi Dave,

I am one of the requesters on a less frequent release. Certainly this does
not need to replace the current release scheme in the development branch:
Galaxy system users who prefer keeping their code up to date can still go
there.

It is just nice to have a separate branch with a less frequent stable
release cycle with the support of fixing major bugs as Hans-Rudolf pointed
out. This fixing support is only needed on the latest stable release.
Regarding the frequency of such a release, I would say it is a bit
dependent on the speed of introducing new major features in Galaxy. I
wouldn't mind to have a 4 or 6 month release cycle in the stable branch if
they synchronize better with the major milestones in Galaxy.

Thanks,
Leon

Message: 3
Date: Wed, 21 Aug 2013 08:57:22 +0200
From: Hans-Rudolf Hotz 
To: Dave Clements 
Cc: Galaxy Dev List 
Subject: Re: [galaxy-dev] Galaxy Release Cycle Length
Message-ID: <521464d2.5010...@fmi.ch>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed

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

-- 
Hailiang (Leon) Mei
Netherlands Bioinformatics Center
BioAssist NGS Taskforce
 - http://ngs.nbic.nl<https://wiki.nbic.nl/index.php/Next_Generation_Sequencing>
Skype: leon_meiMobile: +31 6 41709231
___
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/

Re: [galaxy-dev] Galaxy Release Cycle Length

[Joachim Jacob | VIB |]

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/

Re: [galaxy-dev] Galaxy Release Cycle Length

[Peter Cock]

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/

Re: [galaxy-dev] Galaxy Release Cycle Length

[Ido Tamir]

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  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/


___
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/

Re: [galaxy-dev] Galaxy Release Cycle Length

[Hans-Rudolf Hotz]

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
 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/


___
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/