I don't know what's the position about letting ros run on other systems
that ubuntu, but if the will is to let it run on several OS flavor (which
is the right way to go imo) then sticking to Ubuntu release cycles has just
no sense.
There will always be several types of users that on one hand will wish high
release rate with few changes for agility and on the other one will require
very stable grouped release with LTS for stability.
"agile" users are required to let the project going ahead as they are the
boiling source of idea and great debuggers.
As ROS is going into industry (or simply because it s now a mature system),
LTS and low feature release rate is a must have. People will soon use ROS
in contexts where security and norms are highering inertia of validation
step (required after every update).
Rolling organisation seems adapted to this.
About release cycle duration, what's important is to freeze features at a
fixed date (cause we always have cooler stuff to add but we need to stop
sometime), then let the time required to be stable.
Its quite important for people who plans things ahead (they exist !) to see
what's happening next as it may triggers heavy updating work behing for
users.
Le 31 mai 2013 22:38, "Bill Smart" <
smartw@engr.orst.edu> a écrit :
> As for any consideration for a variable release cycle, I think that too
>> often leads to drawn out development cycles with pent up features and more
>> bugs. Schedules (and budgets, if we had one), force decision making. They
>> ensure that important features do not get hung up on unimportant ones. By
>> setting a goal(deadline), we make it much easier to decide or at least
>> force the decision making process. Does this mean that every release will
>> come out on time. No. Groovy is a good example of this. However, when we
>> fail to meet a deadline we feel that pain, improve and move on to the next
>> release.
>>
>> **
>>
>
> This seems compelling to me, especially given the distributed nature of
> development that we have. On reflection, I think that an ad-hoc release
> cycle might run the risk of leaving packages behind; if there isn't a
> well-specified deadline to work to and there are hard decisions to be made
> (as Shaun suggests), it might lead to some developers not having time to
> get ready for a release. At least, if there's a well-specified, regular
> release cycle, you see the train coming from a long way down the track.
>
> -- Bill
>
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
(text/plain)