On 2013-01-04, at 16:38 , Justin Hopkins <[email protected]> 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/ [email protected]
