> Gets ported to Debian? It already runs on Debian. Pardon my terminology. What I meant was that it would run like a native package, installable from repository, losing the /openils/ directory, etc., in other words, an example of what would be a very significant change from current state.
> As for the numbering, using the last digit results in... > > 2019 - 9.x > 2020 - 0.x You are right, of course. My suggestion implies that we don't worry about that, as it's not an immediate concern. A lot can happen to a piece of software in 8 years, it's a long time. Alexey Lazar PALS Information System Developer and Integrator 507-389-2907 http://www.mnpals.org/ On May 17, 2012, at 12:58 , Thomas Berezansky wrote: > Gets ported to Debian? It already runs on Debian. > > > > I think there is a problem there. Using 2 digits we don't have a problem like > that until the 2099-2100 jump. > > Thomas Berezansky > Merrimack Valley Library Consortium > > > Quoting "Lazar, Alexey Vladimirovich" <[email protected]>: > >> I'm +1 with a date-based scheme, but I would like the transition to be >> smooth and seamless, not a big jolt, even if only perceived. >> >> For this reason, if we do switch to a date-based numbering, may I suggest >> that rather than using YY.MM like Ubuntu, we would just use the last number >> of the year for the first digit of the version, followed by .0 or .1 >> depending on if it's the fist or second major release of that year. Minor >> bug fix releases would be the third digit then. That all starting with the >> March release of 2013. >> >> So, the transition would look something like the following. >> >> Rolling on current numbering: >> 2.2 - current release >> 2.3 - September 2012 release >> >> Now, smoothly and seamlessly transitioning to a date-based scheme, while the >> numbering continues to increase monotonically: >> 3.0 - March release of 2013. Minor releases, if any: 3.0.1, 3.0.2, etc. >> 3.1 - September release of 2013. Minor releases, if any: 3.1.1, 3.1.2, etc. >> 4.0 - March release of 2014. Minor releases, if any: 4.0.1, 4.0.2, etc. >> 4.1 - September release of 2014. Minor releases, if any: 4.1.1, 4.1.2, etc. >> >> And so on. This way we can abandon the current scheme that fell out of use, >> and adopt a new simpler scheme naturally without a big to-do about it. >> Let's reserve a HUGE version jump for when there is a SIGNIFICANT change in >> Evergreen, e.g., it gets ported to Debian, or something of that magnitude. >> >> Alexey Lazar >> PALS >> Information System Developer and Integrator >> 507-389-2907 >> http://www.mnpals.org/ >> >> On May 17, 2012, at 10:53 , Jason Stephenson wrote: >> >>> Quoting "Lazar, Alexey Vladimirovich" <[email protected]>: >>> >>>> Using this scheme, does that mean abandoning minor release numbers? If >>>> yes, I'm against that. If no, what would minor releases look like, >>>> 12.09.1 or 12.09.0.1? Ubuntu does not seem to be using the minor release >>>> numbers. >>> >>> Ubuntu does use minor release numbers. The current "version" of Ubuntu >>> Lucid Lynx is 10.04.4. Thing about the Ubuntu updates is that you typically >>> get them in a rolling fashion, so you might not notice when minor versions >>> are added. >>> >>> The core of my argument is this: >>> >>> Are we focusing on feature releases or timed releases? If the former, then >>> version numbers tied to features/bug fixes makes sense: 2.2.0, 2.2.1, 2.3, >>> 3.0, etc. If the latter, i.e. we're just releasing what's deemed ready on a >>> certain date, then they make less sense, since there is no guarantee of >>> what features are in a given release or what the relationship of features >>> to release is any longer. >>> >>> What it sounds like the majority wants is to have a timed release schedule, >>> but to focus on feature-related versioning schemes. I have no real >>> objection to that, but don't surprised when releases slip because planned >>> features are not ready. >>> >>> As I stated earlier in this thread, my main objection to the feature and >>> dependency-related version scheme is that we aren't using the current one >>> as it is described. I has, de facto, become meaningless. >>> >>> As Rogan has pointed out, the version numbers have a psychological effect >>> on the community: >>> >>> "As for the numbering ... aside from the rational and reasonable reasons >>> for 2.3 versus 3.0, there is the psychological as well. Let's just say a >>> jump to 3.0 will generate some ... anxiety." >>> >>> I think that's another argument for switching to date-base versions or even >>> named releases, dropping version numbering schemes all together. >>> >>> In these days of DVCS where the hurdle of installing from git is hardly any >>> higher than installing from a tarball, version number schemes make less >>> sense than in the past. I have already pointed one project that has >>> abandoned versioned releases in favor of telling people to use git. I think >>> version numbers should be a thing of the past. As a programmer, I've often >>> preferred to install the packages that I care the most about from source >>> and to make sure that I have the absolutely latest code when I encounter an >>> issue. >>> >>> From a free software community perspective, I don't see how support gets >>> any harder under this model. You end up asking all of the same questions. >>> And, you have a very good answer to any unknown problem: update to the >>> latest master and see if the problem persists, if so, we'll open a bug. How >>> is that any different than saying, "Oh, you're on 2.0.5 and the latest is >>> 2.0.11. Update to 2.0.11 and tell us if the problem is still there."? >>> >>> Dan Scott and, I think, Mike Rylander referred to it as Point In Time >>> Support, or PITS. What's a versioned released is not a Point In Time >>> Release? And what is support for that release if not Point In Time Support? >>> Doing it with commit hashes is no different. (That was from IRC for those >>> not following along at home.) >>> >>> The hurdles to installing Evergreen are already fairly high, and if one can >>> install it from a tarball, one can just as easily install it from git. >>> (Instead of wget some-url or downloading in a browser and using scp, you >>> just type git clone some-url.) >>> >>> All of that said, I don't really care what versioning scheme is used. I'd >>> only suggest that it be rational and consistent (and applied consistently >>> as the current one has not). >>> >>> If the focus of development is on regular, date-bound releases, then I'd >>> prefer date-related versions, even ISO date stamps, Ubuntu's scheme is only >>> an example. Even just ratcheting the major version every six months in >>> imitation of Mozilla works in that regard. >>> >>> If the focus is on getting certain features into certain releases, then >>> version schemes like the current one make more sense. >>> >>> Me, I'm happy just using commit hashes and/or the timestamp when I ran the >>> make install command. >>> >>> For someone who claims not to care about the versioning, I sure have spent >>> a lot of time typing about it. >>> >>> -- >>> Jason Stephenson >>> Assistant Director for Technology Services >>> Merrimack Valley Library Consortium >>> Chief Bug Wrangler, Evergreen ILS >> >> > >
