Just to play devil's advocate one man's stagnation is another man's stability. Trust me, I have plenty of folks that would love to see just a stream of tiny little releases that didn't rock the boat any. It's dangerous to say what the whole community thinks without a lot of research, which kind of speaks to Dan's point. I'm hesitant to make decisions because I feel it's obvious a large number of people I never hear from feel a certain way.
(As for upgrade angst, I want to run off daily and not bother with versioned releases and if it was just my library I would, but I have a bigger fish to deal with.) On Fri, Jan 4, 2013 at 3:52 PM, Dan Scott <[email protected]> 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? > -- ---------------------------- Rogan Hamby Headquarters Manager, York County Library System "You can never get a cup of tea large enough or a book long enough to suit me." -- C.S. Lewis <http://www.goodreads.com/author/show/1069006.C_S_Lewis>
