On 21 October 2014 23:25, Wayne Stambaugh stambau...@verizon.net wrote:
3.0.0 sounds good to me.
Wayne
I'm good with the triplet, and any number sounds fine to me! :D
Best Regards,
Brian.
___
Mailing list: https://launchpad.net/~kicad-developers
Le 20/10/2014 17:33, Wayne Stambaugh a écrit :
I'm going to comment on everything posted thus far. I don't have time
to reply on each individual comment. I will say that I am not terribly
thrilled with date style version. I'm not absolutely sure if it causes
grief for package management
On 10/21/2014 12:21 PM, jp charras wrote:
Le 20/10/2014 17:33, Wayne Stambaugh a écrit :
I'm going to comment on everything posted thus far. I don't have time
to reply on each individual comment. I will say that I am not terribly
thrilled with date style version. I'm not absolutely sure if
I feel like we wouldn't use the last digit much in a triplet number
because, IIRC, backporting of fixes is not planned. That being said, I
would also begin with at least 2.1, as Cirilo said.
However, I personally vote for numbering the versions a la MATLAB.
On Mon, Oct 20, 2014 at 1:34 AM, Nick
On Oct 19, 2014, at 4:58 PM, Ian Woloschin i...@woloschin.com wrote:
From a not-really-developer point of view, I do want to at least recommend
the user of year-based release schemes, similar to how Ubuntu or MATLAB, as
opposed to the more traditional triplet style numbering schemes.
On Mon, Oct 20, 2014 at 08:47:54AM -0400, Carl Poirier wrote:
I feel like we wouldn't use the last digit much in a triplet number
because, IIRC, backporting of fixes is not planned. That being said, I
would also begin with at least 2.1, as Cirilo said.
However, I personally vote for numbering
On 20.10.2014 17:25, Marco Ciampa wrote:
On Mon, Oct 20, 2014 at 08:47:54AM -0400, Carl Poirier wrote:
I feel like we wouldn't use the last digit much in a triplet number
because, IIRC, backporting of fixes is not planned. That being said, I
would also begin with at least 2.1, as Cirilo said.
I'm going to comment on everything posted thus far. I don't have time
to reply on each individual comment. I will say that I am not terribly
thrilled with date style version. I'm not absolutely sure if it causes
grief for package management systems such as apt-get or yum. I'm fine
with
For the love of G-d, whatever you do, don't adopt that Altium Season
scheme ... Summer 2011 and what-not. Is Winter 2011 earlier or later
than Winter 2010? What hemisphere are you in? I'm perfectly fine with
the dotted-triplet thing, Major.minor.more-minor -a
Yes, and also these make you fell
Not a dev, but my 2 femto cents:
I really like the #major.#minor.#dev - #buildNo scheme, but I would add
these details about the version incrementation:
2.0
New release, majors changes over the 1.9.
2.1.0
Stable release with new features and bug fixes over 2.0.0.
2.1.25
Development version,
2014-10-20 18:07 GMT+02:00 Benoît Roehr benoit.roehr...@gmail.com:
Not a dev, but my 2 femto cents:
I really like the #major.#minor.#dev - #buildNo scheme, but I would add
these details about the version incrementation:
A lot of info in there, read on.
2.0
New release, majors changes over
On 10/20/2014 12:38 PM, Nick Østergaard wrote:
2014-10-20 18:07 GMT+02:00 Benoît Roehr benoit.roehr...@gmail.com:
Not a dev, but my 2 femto cents:
I really like the #major.#minor.#dev - #buildNo scheme, but I would add
these details about the version incrementation:
A lot of info in there,
I agree with all points here, with one exception and one caveat.
The exception is that it will not work well with git (not an issue here). Git
commit IDs are not ordered and trying to use them as versions is a world of
pain. You’ll just have to trust me on that.
The caveat is that if you’re
2014-10-20 19:00 GMT+02:00 Garth Corral gcor...@abode.com:
I agree with all points here, with one exception and one caveat.
The exception is that it will not work well with git (not an issue here).
Git commit IDs are not ordered and trying to use them as versions is a world
of pain.
On 20/10/2014 18:53, Wayne Stambaugh wrote:
On 10/20/2014 12:38 PM, Nick Østergaard wrote:
2014-10-20 18:07 GMT+02:00 Benoît Roehr benoit.roehr...@gmail.com:
Not a dev, but my 2 femto cents:
I really like the #major.#minor.#dev - #buildNo scheme, but I would add
these details about the
On Oct 20, 2014, at 10:15 AM, Nick Østergaard oe.n...@gmail.com wrote:
2014-10-20 19:00 GMT+02:00 Garth Corral gcor...@abode.com:
I agree with all points here, with one exception and one caveat.
The exception is that it will not work well with git (not an issue here).
Git commit IDs are
I have no objections. Using the triplet is the usual way and has some
minor advantages over a serial numer, in that it it easier to see if
big changes has been made, if the number is given as such. Personally
I don't mind the serial numbering scheme although it can be confusing
when close to the
Here’s my thoughts from an outsiders perspective.
Using proper version numbers is definitely the right way to go. Using commit
numbers is a horrible way to version a project in my opinion. Overlapping
numbers aside, the commit numbers are arbitrary and have no meaning with
respect to the
From a not-really-developer point of view, I do want to at least recommend
the user of year-based release schemes, similar to how Ubuntu or MATLAB, as
opposed to the more traditional triplet style numbering schemes. From
what I've read here KiCad isn't going to be doing more than a couple of
On Mon, Oct 20, 2014 at 8:58 AM, Wayne Stambaugh stambau...@verizon.net
wrote:
In the past we have used the repo commit number as the stable version
number. I'm not sure this is the best idea as there can be overlapping
commit numbers in separate branches. I would like to propose using
2014-10-20 7:19 GMT+02:00 Cirilo Bernardo cirilo.berna...@gmail.com:
On Mon, Oct 20, 2014 at 8:58 AM, Wayne Stambaugh stambau...@verizon.net
wrote:
In the past we have used the repo commit number as the stable version
number. I'm not sure this is the best idea as there can be overlapping
21 matches
Mail list logo
