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

[Joshua Lamos]

I may have entered the conversation late, but can someone explain to me what is gained by not releasing tarballs if release branches are being used within git? 


+1 for the ubuntu style numbering. 

Joshua Lamos 
Senior Systems Analyst 
Emerald Data Networks, Inc. 
678.302.3000 x1009 
http://www.emeralddata.net 



----- Original Message -----

From: "Thomas Berezansky" <tsbere at mvlc.org> 
To: "Evergreen Discussion Group" <open-ils-general at list.georgialibraries.org> 
Sent: Friday, January 4, 2013 11:26:37 AM 
Subject: Re: [OPEN-ILS-GENERAL] Proposal to change Evergreen versioning scheme 

Git doesn't require a local git server. You can use git as a client 
only, you don't even need SSH keys in the community server. 

"git clone git://git.evergreen-ils.org/Evergreen.git" will make an 
Evergreen folder very similar to a tarball extraction, though 
initially set to master. 

Add something like " -b tags/rel_2_3_2" to the command will load the 
specified branch right away, skipping the need to run "git checkout 
tags/rel_2_3_2" in the folder afterwards. 

Granted there are a couple of extra steps when using git, and you need 
more packages if you want to build translations, but it isn't that 
much harder than downloading the tarball and extracting it and we have 
most of the extra steps well documented at this point. 

Thomas Berezansky 
Merrimack Valley Library Consortium 


Quoting Lori Bowen Ayre <lori.ayre at galecia.com>: 

> Just to throw another perspective in here....I DO think the fact that 
> Evergreen is still on version 2.x matters. I might not use the word 
> stagnating, but it creates the impression of large ship slowly making its 
> way when in fact, I know some of the changes have been huge. Giving the 
> version numbers meaning has got to help everyone so either tying them to 
> other underlying changes (e.g. new version of PostgreSQL being required) 
> makes sense. But attaching to the year also makes sense so I (as an outside 
> observer who tries to help people understand what's going on here) would 
> support that! 
> 
> I do have a concern about your talk of eliminating tarballs in favor of 
> Git. While I always urge people to use Git if they can, there are plenty 
> of smaller installations for whom a Git server requirement would put 
> Evergreen out of reach. I guess these people would be obligated to use a 
> service provider as their hosting agency. Or am I missing something? 
> 
> Lori 
> 
> 
> On Fri, Jan 4, 2013 at 8:07 AM, Jason Stephenson <jstephenson at mvlc.org>wrote: 
> 
>> Quoting "Sharp, Chris" <csharp at georgialibraries.org>: 
>> 
>> 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. 
>>> 
>> 
>> They are becoming less so as more projects switch to git or some other 
>> distributed version control system. Mplayer2 is one project that has 
>> abandoned tarballs and versioned releases completely. 
>> 
>> There is another place where versioned releases are tarballs help. That is 
>> with packaging software for distribution with certain GNU/Linux flavors. 
>> Most of their binary packaging systems depend on certain versioning styles 
>> to determine when to upgrade an installed package. Currently, this is not 
>> an issue for Evergreen, since the only way to install it at present is to 
>> compile it from source code. However, several in the community have 
>> ambitions of creating binary packages for Debian, Ubuntu, or Fedora that 
>> users can just install and hopefully everything just works. Not having 
>> tarballs and versions will make their work slightly more difficult. 
>> 
>> If we're voting again on version schemes, I would vote for the 
>> Ubuntu-style YY.MM type. After all, when you run from the master branch 
>> in git, the date you build it is more or less your version. 
>> 
>> 
>> -- 
>> Jason Stephenson 
>> Assistant Director for Technology Services 
>> Merrimack Valley Library Consortium 
>> Chief Bug Wrangler, Evergreen ILS 
>> 
>> 
> 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20130104/516642e7/attachment.htm>