WHAT: Change our version numbering scheme to always include all 3 numbers --
even when the 3rd number is 0.
WHY: I think we made a mistake years ago when we designed the version number
scheme. It's weird that we drop the last digit when it is 0.
WHERE: Trivial patch. See below.
WHEN: Tuesday
Could also start at 1.9.1 instead of 1.9.0. That gives a free number for the
“trunk” nightly builds.
--
~~~ Aurélien Bouteiller, Ph.D. ~~~
~ Research Scientist @ ICL ~
The University of Tennessee, Innovative Computing Laboratory
1122 Volunteer Blvd, suite 309, Knoxville,
Not sure I understand - what do you mean by a "free" number??
On Sep 22, 2014, at 10:50 AM, Aurélien Bouteiller wrote:
> Could also start at 1.9.1 instead of 1.9.0. That gives a free number for the
> “trunk” nightly builds.
>
>
> --
> ~~~ Aurélien Bouteiller, Ph.D. ~~~
>
During the phase where there is not yet a release of “next”, the README and
other documentations employs the number of the not yet released upcoming
version. Sometimes when these gets dispatched, outsiders get confused that they
are using some release version, when in fact they are running a nig
HmmmI see your point, but that means "1.9.5" would actually be lagging
*behind* "1.9.0", which also seems confusing. Usually, if we release a 1.9.0,
we concurrently roll the trunk to 2.0 to avoid the confusion. Is that not
adequate?
On Sep 22, 2014, at 11:30 AM, Aurélien Bouteiller wrote:
On Sep 22, 2014, at 2:39 PM, Ralph Castain wrote:
> HmmmI see your point, but that means "1.9.5" would actually be lagging
> *behind* "1.9.0", which also seems confusing. Usually, if we release a 1.9.0,
> we concurrently roll the trunk to 2.0 to avoid the confusion. Is that not
> adequate?
Hi Folks,
I thought that 1.9.X release would at some point become the 2.0 release.
I thought trunk would go to 2.1 once we branch 1.9 from trunk, no?
What Jeff and I don't like is using 1.9 with implicit 0, then having
1.9.1,1.9.2, etc.
Howard
-Original Message-
From: devel [mailto:d
On Sep 22, 2014, at 4:50 PM, Pritchard Jr., Howard wrote:
> I thought that 1.9.X release would at some point become the 2.0 release.
>
> I thought trunk would go to 2.1 once we branch 1.9 from trunk, no?
Yeah, that's what I was implying. Sorry; I should have stated that directly.
> What Jeff
Gilles - please let me know if/when you think you'll do this. I'm debating
about adding it to 1.8.3, but don't want to delay that release too long.
Alternatively, I can take care of it if you don't have time (I'm asking if you
can do it solely because you have the reproducer).
On Sep 21, 2014,
On 13:50 Mon 22 Sep , Aurélien Bouteiller wrote:
> Could also start at 1.9.1 instead of 1.9.0. That gives a free number
> for the “trunk” nightly builds.
Could also start at 2.1 instead of 2.0. That gives a free boost in
maturity.
More seriously, I'd suggest to use Semantic Versioning[1], wh
Ralph,
here is the patch i am using so far.
i will resume working on this from Wednesday (there is at least one
remaining race condition yet) unless you have the time to take care of it
today.
so far, the race condition has only been observed in real life with the
grpcomm/rcd module, and this is
Folks,
if i read between the lines, it looks like the next stable branch will be
v2.0 and not v1.10
is there a strong reason for that (such as ABI compatibility will break, or
a major but internal refactoring) ?
/* other than v1.10 is less than v1.8 when comparing strings :-) */
Cheers,
Gilles
On Sep 22, 2014, at 8:01 PM, Gilles Gouaillardet
wrote:
> if i read between the lines, it looks like the next stable branch will be
> v2.0 and not v1.10
> is there a strong reason for that (such as ABI compatibility will break, or a
> major but internal refactoring) ?
> /* other than v1.10 is
13 matches
Mail list logo
