[Building Sakai] Change the Sakai CLE release date policy ?

[Neal Caidin]

I have added
https://confluence.sakaiproject.org/display/DOC/Sakai+Release+Date+list

to our checklist here:
https://confluence.sakaiproject.org/display/REL/Release+Communications+Plan

Thanks!
Neal





On Fri, Aug 8, 2014 at 12:38 PM, <yleny at laposte.net> wrote:

> Sam said :
>
>
> >The person from UCDavis writing this blog post has a poor understanding
> of the way Sakai is updated and is most likely >referring to their local
> institution's release of Sakai as opposed to the global updating of Sakai.
>  Sakai code is updated every >day of the year, and after the QA team
> verifies issues, the fixes are merged into maintenance branches on a weekly
> basis.  I >would argue that critical bugs are addressed quite quickly in
> the community, and institutions that are interested in rolling out >bug
> fixes should be rolling out patches several times every term.
>
> The person from UCDavis person has this opinion because you do not see
> several things as developer :
> 1) The web page
> https://confluence.sakaiproject.org/display/DOC/Sakai+Release+Date+list
> was created in june 2014 and was missing in the sakai documentation. With
> this web page, a sakai user/administrator can see that sakai CLE have
>
>  regular updates but without this web page where he can find this
> information ?
> 2) A lot of web server or appplication server administrators are not
> developpers and so you can not ask them to get sakai sources code, patch
> it, compile it and install it on the java application server. It's not
> their job.
> They want only tagged and tested sakai binaries to install on the java
> application server and then they will wait the official tagged release.
>
> For doing so, I also know that quality tests are long and difficult to
> pass especially with a complex software like sakai cle.
> Is it possible to have a minor tagged release with binaries every two
> months to fix the bugs, translations or is it costing too much time for
> qa team and developpers ?
>
>
> >If you want to help increase our velocity of maintenance branch fixes,
> our QA team could use more volunteers to verify issues >that have been
> fixed in trunk but are waiting for verification before being merged to the
> maintenance branch.
> Interesting information if I want to improve sakai.
>
> PS : My message is not a criticism, otherwise I would not have spent so
> much time on my spare (free) time to translate sakai's menus and messages
> in french, translate sakai 10 install documentation in french, improve
> english sakai 10 documentation, create english documentation or improve
> sakai cle wikipedia pages to promote sakai.
>
> Best regards
>
> Yannick
>
>
> > Message du 06/08/14 17:57
> > De : "Sam Ottenhoff"
> > A : yleny at laposte.net
> > Copie à : "Developers Sakai-Dev"
> > Objet : Re: [Building Sakai] Change the Sakai CLE release date policy ?
>
> >
> >
>
>
> > The LMS Transition Initiative
> > http://wheel.ucdavis.edu/lms/
> > extract :
> > "Frequency of Updates. Sakai has not had significant updates in years
> (only bug fixes), and the fixes that do occur are annual, which is not
> frequently enough. The LMS candidates that we are investigating update
> tools, add functionality, and address bugs much more frequently."
> >
>
>
> >
>
>
> >
>
> The person from UCDavis writing this blog post has a poor understanding of
> the way Sakai is updated and is most likely referring to their local
> institution's release of Sakai as opposed to the global updating of Sakai.
>  Sakai code is updated every day of the year, and after the QA team
> verifies issues, the fixes are merged into maintenance branches on a weekly
> basis.  I would argue that critical bugs are addressed quite quickly in the
> community, and institutions that are interested in rolling out bug fixes
> should be rolling out patches several times every term.
>
>
> >
>
>
> >
>
>
>
>
> > When you take a look at all official releases of Sakai CLE web page
> (that I have created), grouped by branch in reverse chronological order:
> > Sakai Release Date list
> > https://confluence.sakaiproject.org/display/DOC/Sakai+Release+Date+list
> > you can see that users neeed to wait 3 months for a minor release
> (2.9.x) and 10 months between a major release (from 2.9.3 to 2.10.0)
>
>
> >
>
>
> >
>
> You are mis-understanding the way maintenance branches work.  The
> maintenance branch (2.9.x, 10.x) is updated frequently as issues are
> verified by our QA team.  Institutions that want frequent bug fixes should
> use the maintenance branches.  Institutions that want less-frequent updates
> can use official tags or releases (2.9.3, 10.0, 10.1).  There is no need to
> wait for official releases if you are interested in frequent updates.
>
>
> >
>
>
> > Is it possible to have a minor release every two months to fix the
> bugs, to have minor improvements and to have the latest translations ?
>
>
> >
>
> If you want frequent updates, use the maintenance branches and don't wait
> for official releases.  An official release is simply a group of volunteers
> coming together to verify, QA, and package the maintenance branch code.  If
> you want to help increase our velocity of maintenance branch fixes, our QA
> team could use more volunteers to verify issues that have been fixed in
> trunk but are waiting for verification before being merged to the
> maintenance branch.
>
>
> >
>
> --Sam
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140808/844b39d6/attachment.html