[sakai2-tcc] [cle-release-team] Emerging consensus to focus on 2.10

[Bryan Holladay]

Please no more 2.x minor releases!  2.10 is confusing in general, plus, as
Chuck said, 2.9 itself doesn't even look anything like 2.0 and shouldn't
have been considered a maintenance release in its own.  4.0 doesn't just
have to be a feature improvement release (which there are plenty of new
features).  It's also showing how the Sakai community is changing and how
we handle our releases.  We need to get rid of the 2nd decimal point in the
releases and move to just single: 4.0, 4.1, 4.2, 5.0, 5.1, 5.2; otherwise,
we'll get stuck in release 4.x like we did in 2.x.  I'd like to quote
someone on this:

"We are struggling with going from 2.x to 4.x because we have to argue that
the next release will be breakthrough enough to merit such a major version
change.  If we keep the same 3 digit versioning system, we'll run into this
same rut for the next version we jump to.  If we move to the 2 digit
version (4.1, 4.2, 5.0, ...) then we won't have to feel like there must be
an earth shattering change that merits a major release version update.
 This would better represent Sakai's true development cycle of incremental
changes that, when added together, equals a large step forward, as opposed
to giants leaps following by minor changes, which our current versioning
suggests."  -Bryan Holladay


On Mon, Sep 9, 2013 at 10:03 AM, Mark J. Norton
<markjnorton at earthlink.net>wrote:

>  As strange as it is for me to agree with anything Chuck says, I agree
> with him.  It's time to reboot Sakai and take a stab at some of those
> really big issues.  Technology marches on and it's easy to be left behind.
>
> Jira is full of good suggestions, so there is no lack of things to
> tackle.  Still, I'd like to see some architectural review done.  Perhaps we
> should build support for TinCan into the kernel.  We might consider support
> for a database that isn't owned by Oracle.  Sakai runs okay in a cloud
> environment, but what could we do to make it SCREAM there?  There are
> issues that came up in Sakai 0.5 that have NEVER been addressed (like full
> back button support, for example).  We should move up to Java 7, too.
>
> Yeah, it's a time to consider incremental improvements, too, but let's
> think big.  Let's think about what it will take to put Sakai back on the
> CIO radar and bring back the buzz of the early days.
>
> - Mark Norton
>
>
> On 9/9/2013 9:50 AM, Charles Severance wrote:
>
> I think that Noah is wrong and disagree with Beth below.
>
>  We should expect a relatively small 2.9.4 release that is
> essential/critical bug fixes only and then a 4.0.  Starting immediately we
> should work towards a trunk-based 4.0 release and move 2-9-x into
> "maintenance mode".  We need to spend some time working on trunk and then
> begin to focus nearly all of our efforts of dev-testing and QA of trunk and
> put in as little effort as we can on 2-9-x.  Starting *today* - not nine
> months from now.
>
>  To those who think that we need yet-still-more new features before we
> are "worthy" of a 4.0 - you are *could not be more* wrong.
>
>  I would suggest that you download Sakai *2.0*, bring it up and then
> compare it to trunk or even 2.9.3 in terms of features, performance and
> look and feel.   What we have in trunk and even the 2.9.3 release bears so
> little resemblance to the Sakai 2.0 release that we probably should have
> called 2.9.3 Sakai 4.0.  Calling Sakai 2.9.3 a "minor release" of Sakai 2.0
> is completely misleading and badly confusing to the marketplace.
>
>  Please explain to me how a 2.10 release is somehow a maintenance release
> of that 2005 software we called "Sakai 2.0".
>
>  If you want to get a sense of what the lack of a major new version is
> dong to us all - look at this Twitter thread:
>
>  https://twitter.com/PhilOnEdTech/status/374947773210062848
>
>  This sucks for commercial purveyors of Sakai and sucks for on-campus
> people trying to advocate that Sakai was not dead three years ago.  Sakai
> is still one of the best LMS's on the market right now and its vector is
> strong.  Three years ago members of the Sakai community were our own worst
> enemy.  We formed the TCC so we would have leadership that would not be
> "our own worst enemy" - but if we degrade into group-think and convince
> ourselves that the next major release needs to be labelled a minor release
> - we *have* become our own worst enemy.
>
>  We as insiders all have our little pet peeves as to what we should fix.
>  That is normal - all projects have that.   Things like when to declare a
> major new version should not be blocked by people trying to force others to
> work on their own pet peeves.
>
>  It time to move on.
>
>  /Chuck
>
>  On Sep 9, 2013, at 8:32 AM, Beth Kirschner <bkirschn at umich.edu> wrote:
>
> It is now September -- we have been debating this since the conference in
> June. If we don't very quickly come to consensus on a release schedule, we
> can pretty much forget about a major release in the first half of 2014.
> There is a lot of good stuff in trunk that should be QA'd and released. The
> longer we wait on getting trunk QA'd and released, the more problematic it
> will be to put out a stable release. More code change == more risk of bugs.
> Now is not the time for indecision. Nor is it the time for putting more
> into a release that's not in there now. I support Noah's approach of a 2.10
> followed by a 4.0.
>
> - Beth
>
>
>
>
> _______________________________________________
> sakai2-tcc mailing listsakai2-tcc at collab.sakaiproject.orghttp://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
>
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130909/d66c0617/attachment.html