On 2013-01-04, at 09:49 , "Sharp, Chris" <[email protected]> wrote:
> Hi all, > >> * The current scheme creates a perception that Evergreen is >> stagnating - version 2 since 2010 > > I don't agree with this. It took years and years for the Linux kernel to > move from major version 2 to major version 3, for instance, and no one thinks > it's stagnating. I would argue that Evergreen is different from the Linux kernel in the sense that a much wider audience, from library directors to developers, deals with Evergreen directly. That is not true for the Linux kernel. > >> * Under the current scheme Evergreen will reach version 3 in 2016(!) > > I don't see this as a problem… It is not a problem per se, except if perceived as stagnation by those who are not following Evergreen development closely > >> On the subject of numbered releases in general: I think we should >> ditch them entirely and tell people to run out of git. I also >> understand that is not likely to happen, but I am saying it anyway. > > Anyone who pays attention to IRC discussions knows my take on this, but > numbered releases are important for organizations that need to move more > slowly than the developers as far as feature additions and changes to core > functionality go. The main issues around this are the following: > > 1) end user documentation and training - organizations that support a large > consortium of diverse libraries need some solid ground to develop and > implement training and documentation for end users. If the software is > constantly changing, documentation and training content grows stale fast, and > we can't spend all our time playing catch-up > 2) technical support staff - we need to have a good handle on how the > software is "supposed" to work - if that's changing constantly, that's not > (as) possible to do > 3) frontline staff and patrons - our users become very frustrated and anxious > with what appears to them to be arbitrary change. In our case, we'd like the > software to just serve the purposes it's meant to serve without being the > main focus of public library staff's daily work. That would not be possible > if we were streaming in new features as they are developed. > 4) related to the above points, we do not want our production system to be a > testbed for new features I could not agree more. > Version numbers also help system administrators know which > features/bugfixes/etc. are in which release. See my comments on this bug > regarding the currently unversioned SIP Server: > https://bugs.launchpad.net/sipserver/+bug/1083290. Different subject, but I read through the bug and agree that it would be a good idea to number SIPServer releases. I was a bit surprised to find it was not the case already. > >> Even *with* the numbered releases I think we should ditch tarballs >> and point people at git *anyway*, for that matter. Which is another "not >> likely to happen" thing. > > As long as the tagged git version and the tarball match, I have no problem > with suggesting either, but I think tarballs are standard and expected in > F/LOSS projects. I think it may be too early to ditch tarballs completely. I would like to see Evergreen packaged and installable from linux distribution repositories before that occurs. > >> On the subject of the proposed scheme: I disagree with the last digit >> of the year. If we are going with any form of date-based numbering >> then I think we should go for last 2 digits of the year with the >> second number being the month. The third number would start with 0 >> and increment once for each maintenance release. > >> If we decide to change, I would also vote for the Ubuntu-style naming >> scheme Thomas describes. (IIRC, Jason S. was also a proponent of >> this scheme). >> >> As an example, the next release would be the 13.03.0 release. > > +1 > > Chris Aleksey Lazar PALS IS Developer and Intergrator 507-389-2907 http://www.pals.org/ [email protected]
