Hello Wayne,
Am 10.07.19 um 21:12 schrieb Wayne Stambaugh:
> The problem with d & e is I do not think they address the user
> interpretation of our version string. Using "master" as a prefix or
> suffix probably doesn't mean much to many users. You may be expecting
> users to be more informed ab
The problem with d & e is I do not think they address the user
interpretation of our version string. Using "master" as a prefix or
suffix probably doesn't mean much to many users. You may be expecting
users to be more informed about versioning than they actually are.
Wayne
On 7/10/19 12:19 PM,
d: keep it as is
e: prepend the branch to what we currently have
On Wed, 10 Jul 2019 at 17:55, Wayne Stambaugh wrote:
>
> On 7/9/19 4:49 PM, Carsten Schoenert wrote:
> > Hello Nick,
> >
> > Am 09.07.19 um 21:57 schrieb Nick Østergaard:
> >> I have a hard time to understand how 5.99 is better to
On 7/9/19 4:49 PM, Carsten Schoenert wrote:
> Hello Nick,
>
> Am 09.07.19 um 21:57 schrieb Nick Østergaard:
>> I have a hard time to understand how 5.99 is better to describe a
>> development version. 6.00 was already a bad way to describe it.
>> People also were confused. To me .99 seems very a
On 2019-07-09 9:26 a.m., Steven A. Falco wrote:
I'd vote for the .99 approach, assuming I get a vote. :-)
Using .9 or .99 for the minor version number when the major version number
is about to go up by 1 is a fairly common numbering system. Someone
suggested using a tag instead. The problem w
Hello Nick,
Am 09.07.19 um 21:57 schrieb Nick Østergaard:
> I have a hard time to understand how 5.99 is better to describe a
> development version. 6.00 was already a bad way to describe it.
> People also were confused. To me .99 seems very arbitrary. Why not
> .1234?
simply your mind is interp
An option could be to prepend the branch name via something like:
git symbolic-ref -q --short HEAD
To the git describe --long we already have.
On Tue, 9 Jul 2019 at 21:57, Nick Østergaard wrote:
>
> I have a hard time to understand how 5.99 is better to describe a
> development version. 6.00 wa
I have a hard time to understand how 5.99 is better to describe a
development version. 6.00 was already a bad way to describe it. People
also were confused. To me .99 seems very arbitrary. Why not .1234?
On Mon, 8 Jul 2019 at 23:20, Eeli Kaikkonen wrote:
>
>
>
> ma 8. heinäk. 2019 klo 23.47 Nick
ti 9. heinäk. 2019 klo 19.45 Simon Richter (simon.rich...@hogyros.de)
kirjoitti:
> I still think it is a bit confusing to have a tag
> on something that is not a release.
>
"git tag" reveals to me that 5.1.0-dev is already a tag, and it's not a
release. Right?
Eeli Kaikkonen
Hi,
On Tue, Jul 09, 2019 at 09:26:11AM -0400, Steven A. Falco wrote:
> I'd vote for the .99 approach, assuming I get a vote. :-)
The main difficulty is the way the version number generation is
implemented. We use "git describe" to get the name of the last tag, then
add the number of commits and
On 7/8/19 10:41 PM, Reece R. Pollack wrote:
> On 7/8/19 10:36 PM, Kevin Cozens wrote:
>> On 2019-07-08 5:10 p.m., Dino Ghilardi wrote:
>>> think about the linux kernel versioning number scheme: even subversion
>>> number means stable release. Odd subversion number means
>>> experimental/development
On 7/8/19 10:36 PM, Kevin Cozens wrote:
On 2019-07-08 5:10 p.m., Dino Ghilardi wrote:
think about the linux kernel versioning number scheme: even subversion
number means stable release. Odd subversion number means
experimental/development branch.
The kernel used to follow the odd/even numberin
On 2019-07-08 5:10 p.m., Dino Ghilardi wrote:
think about the linux kernel versioning number scheme: even subversion
number means stable release. Odd subversion number means
experimental/development branch.
The kernel used to follow the odd/even numbering scheme but they stopped
doing that dur
On 2019-07-08 4:47 p.m., Nick ??stergaard wrote:
How is a number like 99 being any better than the latest release tag?
The release tag doesn't appear in the title bar of the running program.
--
Cheers!
Kevin.
http://www.ve3syb.ca/ | "Nerds make the shiny things that
https://www
ti 9. heinäk. 2019 klo 0.10 Dino Ghilardi (dino.ghila...@ieee.org)
kirjoitti:
> As an alternative to the .99 numbering (that should work well until 5.98
> stable version is reached (! :-) ) )
>
It was already decided that there won't be even 5.2, let alone 5.98.
Whatever the next stable will incl
ma 8. heinäk. 2019 klo 23.47 Nick Østergaard (oe.n...@gmail.com) kirjoitti:
> How is a number like 99 being any better than the latest release tag?
>
>
Did you read the original post, about the current problem? What is the
"latest release tag"? 5.1.0 or 5.1.2? Number like 5.99 is unambiguous (and
As an alternative to the .99 numbering (that should work well until 5.98
stable version is reached (! :-) ) ) also think about the linux kernel
versioning number scheme: even subversion number means stable release. Odd
subversion number means experimental/development branch. At every release
of th
My brain can visually parse 5.99. I have to actually read the current tags and
think about them before I can figure out what they represent.
> On 8 Jul 2019, at 21:47, Nick Østergaard wrote:
>
> How is a number like 99 being any better than the latest release tag?
>
> On Mon, 8 Jul 2019 at 22
How is a number like 99 being any better than the latest release tag?
On Mon, 8 Jul 2019 at 22:43, Eeli Kaikkonen wrote:
>
>
>
> ma 8. heinäk. 2019 klo 21.23 Wayne Stambaugh (stambau...@gmail.com) kirjoitti:
>>
>> Honestly, I don't have a strong preference
>> one way or another. If someone can c
ma 8. heinäk. 2019 klo 21.23 Wayne Stambaugh (stambau...@gmail.com)
kirjoitti:
> Honestly, I don't have a strong preference
> one way or another. If someone can come up with a system that's
> workable for everyone, that's fine by me. I don't have an issue with
> using something like 5.99.0.
>
I
I find the current scheme confusing.
I like the 5.99 idea….
Cheers,
Jeff.
> On 8 Jul 2019, at 20:03, Wayne Stambaugh wrote:
>
> On 7/8/19 2:58 PM, Kevin Cozens wrote:
>> On 2019-07-08 2:38 p.m., Nick ??stergaard wrote:
>>> @Kevin, And the version is not just the tag and number of commits, but
On 7/8/19 2:58 PM, Kevin Cozens wrote:
> On 2019-07-08 2:38 p.m., Nick ??stergaard wrote:
>> @Kevin, And the version is not just the tag and number of commits, but
>> also the sha1.
>
> That is true when reporting bugs. I don't care about the sha1 when I
> want to make sure I am running the right
On 2019-07-08 2:38 p.m., Nick ??stergaard wrote:
@Kevin, And the version is not just the tag and number of commits, but
also the sha1.
That is true when reporting bugs. I don't care about the sha1 when I want to
make sure I am running the right version of KiCad. That is particularly
important
@Wayne I think the current one is fine.
@Kevin, And the version is not just the tag and number of commits, but
also the sha1.
On Mon, 8 Jul 2019 at 20:23, Wayne Stambaugh wrote:
>
> It used to be 6.0.0-dev but apparently this caused package version
> issues so it was dropped in favor of the curr
It used to be 6.0.0-dev but apparently this caused package version
issues so it was dropped in favor of the current version tagging scheme.
There has already been at least one confused bug reporter about the
current versioning scheme. Honestly, I don't have a strong preference
one way or another.
Greetings, all.
I just ran across something odd with the version number shown by the KiCad
program(s).
I compiled and installed git master. When I ran it the version number
reported is 5.1.0.1195. As I also compile and run the 5.1 version I thought
I had a mix up when I did the compile. When
26 matches
Mail list logo
