On 2013-01-04, at 14:52 , Dan Scott d...@coffeecode.net 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
Hi Alexey,
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
On Wed, Jan 09, 2013 at 02:07:58PM -0500, Kathy Lussier wrote:
Hi Alexey,
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
--
*
Daniel Wells, Library Programmer Analyst d...@calvin.edu
Hekman Library at Calvin College
616.526.7133
On 1/4/2013 at 3:52 PM, Dan Scott d...@coffeecode.net wrote:
In the end, I'd really like to not have this
On 2013-01-07, at 09:46 , Dan Wells d...@calvin.edu wrote:
--
*
Daniel Wells, Library Programmer Analyst d...@calvin.edu
Hekman Library at Calvin College
616.526.7133
On 1/4/2013 at 3:52 PM, Dan Scott
Or, in honor of the new year, I'd like to suggest we bump the version to 10.0
and start working our way down to 0.0. This plan has the following
advantages:
- we would probably get the project 15 minutes of fame on Slashdot or
something
- it meets Galen's monotonicity requirement, so we
On 01/07/2013 01:23 PM, Jason Etheridge wrote:
I'm with you, but if we do ever go past zero and into negative
numbers, I want a green screen telnet interface for staff use.
You can have that now:
http://git.mvlcstaff.org/?p=jason/issa.git;a=summary
--
Jason Stephenson
Assistant Director for
Hi All - it has been pointed out to me off list that mentioning Horizon 8
to the Evergreen crowd is akin to flame baiting - just want to repeat here
what I said off list - that was not my intent, I was simply trying to say
that I think the versioning thing is probably a systems/developers woe and
Quoting Justin Hopkins jus...@mobiusconsortium.org:
Why are we so focused on the numbering scheme? I don't think the time
spent worrying about what number we are on does anything to improve
the project.
I pretty much agree with you. However, version numbers are important
to end users and
On Fri, Jan 4, 2013 at 9:50 AM, Thomas Berezansky tsb...@mvlc.org wrote:
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
Quoting Sharp, Chris csh...@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
On 2013-01-03, at 18:35 , Justin Hopkins jus...@mobiusconsortium.org wrote:
Why are we so focused on the numbering scheme? I don't think the time
spent worrying about what number we are on does anything to improve
the project.
For our organization, managing expectations and perceptions of
On 2013-01-04, at 08:47 , Jason Stephenson jstephen...@mvlc.org wrote:
Quoting Justin Hopkins jus...@mobiusconsortium.org:
Why are we so focused on the numbering scheme? I don't think the time
spent worrying about what number we are on does anything to improve
the project.
I pretty much
Just to throw another perspective in hereI 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
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
On 2013-01-04, at 08:50 , Thomas Berezansky tsb...@mvlc.org wrote:
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
On 2013-01-04, at 09:07 , Bill Erickson ber...@esilibrary.com wrote:
As soon as we moved to time based releases, it seems like everyone, including
myself, starting referring to the releases by their release date.. e.g. the
2013 Fall Release. I was mildly against it at first, but including
Hi,
On Fri, Jan 4, 2013 at 7:07 AM, Bill Erickson ber...@esilibrary.com wrote:
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).
All that I ask of a version number that it increase
://www.emeralddata.net
- Original Message -
From: Thomas Berezansky tsb...@mvlc.org
To: Evergreen Discussion Group open-ils-general@list.georgialibraries.org
Sent: Friday, January 4, 2013 11:26:37 AM
Subject: Re: [OPEN-ILS-GENERAL] Proposal to change Evergreen versioning scheme
Git
Thomas,
Thanks for that explanation. If that's the case I'm all for encouraging
people to move in that direction and we should make sure we have good
documentation of that approach whenever possible (which we may already...)
Lori
On Fri, Jan 4, 2013 at 8:26 AM, Thomas Berezansky
Just thought I'd throw this out there
Here's an interesting proposal that I encountered last week called Semantic
Versioning, which isn't super different from what is being done now.
http://semver.org/
The only challenge with this is defining a public API -- while we have the
various OpenSRF API
I'm not sure I agree that version numbers aren't important to marketing
Evergreen. Non-techie administrators have been trained to see large
numbers before the dot meaning that there should be a lot of major features
and that small numbers after it means that those features are mature and
bug
For those of us not up-to-date in our Order Theory studies, would Galen
care to explain what monotonically refers to in this discussion.
Intrigued in Petaluma
On Fri, Jan 4, 2013 at 10:04 AM, Rogan Hamby rogan.ha...@yclibrary.netwrote:
I'm not sure I agree that version numbers aren't important
Hi all,
I've been sitting on the sidelines of this discussion because I count
myself as one of those people who doesn't particularly care about a
version numbering system, but is very concerned with consistent release
schedules and the new features/bug fixes that make up a release. The
On 01/04/2013 10:33 AM, Kathy Lussier wrote:
I disagree that there is a perception that Evergreen is stagnating
because we're still at 2.x, but if the problem is that we really should
be at 3.0 or 4.0 because of the big changes that have come with recent
releases, then maybe the solution is
On 2013-01-04, at 12:47 , Joshua D. Drake j...@commandprompt.com wrote:
On 01/04/2013 10:33 AM, Kathy Lussier wrote:
I disagree that there is a perception that Evergreen is stagnating
because we're still at 2.x, but if the problem is that we really should
be at 3.0 or 4.0 because of the
On 2013-01-04, at 12:04 , Rogan Hamby rogan.ha...@yclibrary.net wrote:
If we move to a new versioning scheme I just want it to have enough of an
advantage that it will be worth re-educating people who can't follow the
discussion that's on this list.
I think the main advantage of moving to
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
As a postscript,
P.S.
My previous statements are not an argument against change. As I said
before, I have nothing against eating my liver hash (apologies to those who
like liver) for greater health but I want the benefit to be clear and
substantial for the hassle I can guarantee you I (and
On 2013-01-04, at 09:49 , Sharp, Chris csh...@georgialibraries.org 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
On 2013-01-04, at 14:23 , Rogan Hamby rogan.ha...@yclibrary.net
wrote:
As a postscript,
P.S.
My previous statements are not an argument against change. As I said before,
I have nothing against eating my liver hash (apologies to those who like
liver) for greater health but I want
Hi,
And in this case, the order being determined by time. In particular, if we
were to adopt Ubuntu-style version numbers and release a 13.04, that it
would be a niceness to not pull a Windows and decide next year to release
4.0.
Regards,
Galen
On Fri, Jan 4, 2013 at 10:43 AM, Rogan Hamby
Alexey,
I think you're way off when you say that there's a wider audience dealing
with Evergreen directly than with PostgreSQL and Linux. You must know that
the former has many thousands of direct users, and the latter millions.
Plenty of people concerned with those projects are in the
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
I will concur with Lebbeous that library directors do learn about
PostgreSQL and Linux - not in the same way, not based on the same data
points that a systems administrator does but they do. And that's a bit of
my point, the versioning is a data point short cut for them, a short hand
if you will
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
On 01/04/2013 12:30 PM, Lazar, Alexey Vladimirovich wrote:
* 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
This
I wasn't planning on jumping into this conversation, but as someone who
is not truly a tech professional, but has been thrust into the role over
the last few years, I think the one important point to make about
Evergreen versus Linux or SQL is that what version I'm running seems to
matter much
Thank you, Joe. You explained with so much clarity exactly what I was trying to
say about comparing Evergreen with Linux, PostgreSQL, or other FOSS projects.
On 2013-01-04, at 15:15 , Joe knuev...@oplin.org wrote:
I wasn't planning on jumping into this conversation, but as someone who is
not
I think Dan hit the nail on the head, especially with his first and last
paragraphs.
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:
On 2013-01-04, at 16:38 , Justin Hopkins jus...@mobiusconsortium.org 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
Hello:
I won't pretend to understand all of the options re version schema
discussed herein but as non-techie, I can certainly say that I've never
worried at all about how our versions are numbered. I truly don't
understand the fuss. I certainly know what version of Windows I'm using,
but
Hello.
I would like to propose a change to the official Evergreen versioning scheme.
Rather than then the current scheme that attempts to tie version numbers to
various code changes, I propose that we switch to a more simple and predictable
calendar-related scheme that better aligns with the
Why are we so focused on the numbering scheme? I don't think the time
spent worrying about what number we are on does anything to improve
the project.
I suspect this is coming up because of bericks recent post about
release scheduling - which I (personally) do think would improve the
project.
44 matches
Mail list logo
