[OPEN-ILS-GENERAL] Proposal to change Evergreen versioning scheme

Sat Jan 5 10:59:25 EST 2013

Hi All - it has been pointed out to me off list that mentioning Horizon 8
to the Evergreen crowd is akin to flame baiting - just want to repeat here
what I said off list - that was not my intent, I was simply trying to say
that I think the versioning thing is probably a systems/developers woe and
not that big a deal to us non-techies.  Here's what I said in my reply to
the flame baiting accusation/suggestion:

"Believe me no offense intended, the library I worked for at the time used
Sirsi so we weren't directly affected but I was so outraged by that move, I
can't imagine how I would have felt if we'd been a Horizon library. It does
still seriously rankle for me so I can only imagine how those really
betrayed still feel.  My trust in vendors will never return to its former
level (not that it was ever that high).  The consortium we belonged to at
the time made the decision to stay with the newly merged Sirsi/Horizon -
that was one of the many things that prompted us to move to Evergreen.
I truly was just trying to provide a non-techie's perspective on the
discussion - I think this is a developer/systems woe."

Regards, Cynthia

Regards, Cynthia

On Fri, Jan 4, 2013 at 10:07 PM, Cynthia Williamson
<crwbookgirl at gmail.com>wrote:

> Hello:
> I won't pretend to understand all of the options re version schema
> discussed herein but as non-techie, I can certainly say that I've never
> worried at all about how our versions are numbered.  I truly don't
> understand the fuss. I certainly know what version of Windows I'm using,
> but seriously, don't ask me about Firefox or Picassa or iTunes, etc. - no
> idea of the actual numbers of the versions I'm using. (I do know how to
> find out if I need to though.)
> I will always remember Horizon 8.0 (that whole fiasco still offends me)
> but I no longer remember what version of Sirsi (Unicorn?) we were using
> before we migrated to Evergreen.  I have worked on more than one ILS
> migration and while the vibrancy of development work on the ILSs under
> consideration was important, it never occurred to me to see them as robust
> or stagnant by looking at their version schema.  I asked about upgrades -
> when/how they were scheduled, communicated, etc.
>
> Dan's suggestion to simply wipe the offending paragraphs from the wiki so
> that we are indeed doing what we say we're doing works for me. If there's
> some kind of vote going on, I'd vote for that.
>
> Regards, Cynthia
> Mohawk College Library
> Hamilton, ON
>
> --
> *People have the power
> The power to dream, to rule
> To wrestle the earth from fools*
>
>
> On Fri, Jan 4, 2013 at 6:28 PM, Lazar, Alexey Vladimirovich <
> alexey.lazar at mnsu.edu> wrote:
>
>>
>> On 2013-01-04, at 16:38 , Justin Hopkins <justin at mobiusconsortium.org>
>> wrote:
>>
>> > I think Dan hit the nail on the head, especially with his first and
>> last paragraphs.
>>
>> Justin, it was clear from your first response to my post that you seem to
>> be frustrated that I brought up this topic.
>>
>> Even though I think I generally understand your sentiment, what's your
>> idea? That we keep *not* following the current versioning scheme, in
>> essence not having a version scheme?
>>
>> If we have one, let's use it. If it does not work, because it is too
>> complicated to maintain, let's consider a simple low-maintenance scheme
>> instead, which was what my proposal was all about, basically.
>>
>> >
>> > Justin Hopkins
>> > Manager Information Technology
>> > 573-808-2309
>> >
>> > On 1/4/13 2:52 PM, Dan Scott wrote:
>> >> On Fri, Jan 04, 2013 at 03:21:08PM -0500, Rogan Hamby wrote:
>> >>> I would disagree.  It's not this one:
>> >>> http://www.open-ils.org/dokuwiki/doku.php?id=versioning
>> >>>
>> >>> But, I would propose that we are following one based largely on the
>> >>> developer's perception of what are major and minor features and
>> impact for
>> >>> users.  I've been there for a few of those discussions and those were
>> the
>> >>> concerns voiced when discussing version numbers.  Unintentional?  I
>> can't
>> >>> speak to that.  But, to me what is already being done, as abstract
>> and ill
>> >>> defined as it is (and I think that is part of what bothers some) -
>> works.
>> >>>  I'm fine with things as they are.  It works with the larger
>> community's
>> >>> goals (or at least mine) and a raw number means something to the
>> front line
>> >>> users.
>> >> If we had a marketing team, and they had done some research that showed
>> >> that version numbers actually matter when it comes to perceptions of a
>> >> library system's stagnation (or not) and adoption of said system, then
>> I
>> >> would defer to their decision. But as far as we know, we don't have a
>> >> marketing team, and I haven't seen any citations about such research on
>> >> generic software products in the discussion to date.
>> >>
>> >> On the argument that we're not following our current versioning scheme
>> >> criteria around the major number - I like James' pointer to the
>> semantic
>> >> versioning proposal, and that fits quite well with library
>> >> versioning semantics that we're already doing (to some extent) via
>> >> autotools.
>> >>
>> >> That said, given that some major piece of infrastructure is likely to
>> >> always change (Dojo or PostgreSQL or XULRunner or Apache or any of the
>> >> other umpteen dependencies that we have), we could either strike the
>> >> pertinent clauses from the versioning scheme in the wiki, or alter it
>> to
>> >> say that it will be incremented when major features are added.
>> >>
>> >> As someone who is (currently very slowly) working towards packaging
>> >> Evergreen, I would much prefer version numbers and tarballs to just
>> >> pulling directly from git. Tarballs are a much lower barrier to entry
>> >> and having a release artifact means that (in theory) the people testing
>> >> the release candidates are all testing the same base code, without
>> >> differences based on their local version of tools that generate the
>> code
>> >> that is in the tarball and not in git.
>> >>
>> >> I don't like the date approach very much as, although we've agreed to
>> >> time-based releases, we've also agreed to let the release date slip if
>> >> there are known blockers. So we could end up with 13.04 / 13.11 / 14.05
>> >> / 14.10, and that would lead to references to 13.10 having to be
>> updated
>> >> in multiple places to 13.11 if we slip. Bah.
>> >>
>> >> I think a lot of the "Is it going to be a huge pain to upgrade? Or is
>> it
>> >> just a minor upgrade?" angst would be diminished if we (devs and
>> release
>> >> managers) did a better job of communicating expectations about each
>> >> upcoming release. We pledged to do this at EGConf 2012 and had a good
>> >> start, but need to stay vigilant on this front - and pitch in on the
>> >> documentation (release notes & upgrade notes).
>> >>
>> >> I will admit to suffering from fatigue around this discussion, which
>> >> last came up in May:
>> >>
>> http://libmail.georgialibraries.org/pipermail/open-ils-dev/2012-May/008203.html
>> >>
>> >> In the end, I'd really like to not have this discussion come up on a
>> >> regular basis. There's code and docs and tests and websites to be
>> worked
>> >> on, and a product that is solid and reliable and easy to understand and
>> >> use is going to succeed no matter how much the version numbers diverge
>> >> from the scheme documented on a wiki page. And if the current problem
>> >> can be rectified by striking out two clauses from the wiki page, why
>> >> don't we just do that so we can focus on everything else we have to
>> work
>> >> on?
>> >
>>
>> Aleksey Lazar
>> PALS
>> IS Developer and Intergrator
>> 507-389-2907
>> http://www.pals.org/
>> alexey.lazar at mnsu.edu
>>
>>
>>
>>
>
>
> **
>
>

-- 
*People have the power
The power to dream, to rule
To wrestle the earth from fools*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20130105/9c6a783b/attachment.htm>