On Friday, January 15, 2021 9:11:03 AM WET Jean-Marc Lasgouttes wrote:
> Yes, it is very immediate. All you have to do is to go to the web site
> of each and every package you want to use and check what they mean by
> 3.0 ! I propose something where prime numbers are used for development
>
On Fri, Jan 15, 2021 at 10:11:03AM +0100, Jean-Marc Lasgouttes wrote:
> I propose something where prime numbers are used for development releases,
> this would be very simple too.
You made my day :)) P
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
Le 13/01/2021 à 11:22, José Abílio Matos a écrit :
On a more serious note, I do not insist on the particular use of the x.0
convention. I find it elegant and it gives a nice justification, for example,
why gcc stable releases always starts at .1. FWIW gcc started the new
numbering scheme at
On Wednesday, January 13, 2021 8:27:28 PM WET Pavel Sanda wrote:
> The question really is why it should be wrong to give new major version
> +0.1.
>
> Anyway, I do not see that this subthread is moving in a constructive
> direction, so it's perhaps best to agree that we disagree
I agree, I tried
On Wednesday, January 13, 2021 2:37:54 PM WET Pavel Sanda wrote:
> Fortunately I do not have to rely only on my memory
>
> Wiki: Sat Nov 15 18:59:02 2008 : LyX 2_0: Wiki pages creation
> SVN:Sun Dec 7 18:09:18 2008 : [Cvslog] r27798 Makefile.am: PSpell and
> ISpell was removed for LyX 2.0
On Wed, Jan 13, 2021 at 05:20:24PM +, José Abílio Matos wrote:
> On Wednesday, January 13, 2021 3:31:01 PM WET Pavel Sanda wrote:
> > No, as I have written in my first reply my proposal is to stay with single
> > digits as long as possible (i.e. for 2 maxing at 2.9) with an option to use
> >
On Wednesday, January 13, 2021 3:31:01 PM WET Pavel Sanda wrote:
> No, as I have written in my first reply my proposal is to stay with single
> digits as long as possible (i.e. for 2 maxing at 2.9) with an option to use
> sporadic bumps to +1 version for unusual events (like unicode, Qt3->Qt4,
>
Am Wed, 13 Jan 2021 16:31:01 +0100
schrieb Pavel Sanda :
> On Wed, Jan 13, 2021 at 03:12:10PM +, José Abílio Matos wrote:
> > On Wednesday, January 13, 2021 2:37:54 PM WET Pavel Sanda wrote:
> > > I guess that's the point where we break. I agree that moving from 2 to 3
> > > signals major
On Wed, Jan 13, 2021 at 03:12:10PM +, José Abílio Matos wrote:
> On Wednesday, January 13, 2021 2:37:54 PM WET Pavel Sanda wrote:
> > I guess that's the point where we break. I agree that moving from 2 to 3
> > signals major change. At the same time once some project moves to double
> > digits
On Wednesday, January 13, 2021 2:37:54 PM WET Pavel Sanda wrote:
> I guess that's the point where we break. I agree that moving from 2 to 3
> signals major change. At the same time once some project moves to double
> digits versions my experience is that I am no more keeping track which
> version
On Wed, Jan 13, 2021 at 01:55:24PM +, José Abílio Matos wrote:
> > I hope my memory serves me well, but the major reason we did not go the
> > predictable route of 1.6, 1.7, 1.8, 1.9, 2.0, 2.1 etc was your own push for
> > 2.0 at the Berlin meeting. I can even remember at which corner of the
On Wednesday, January 13, 2021 11:51:53 AM WET Pavel Sanda wrote:
> I hope my memory serves me well, but the major reason we did not go the
> predictable route of 1.6, 1.7, 1.8, 1.9, 2.0, 2.1 etc was your own push for
> 2.0 at the Berlin meeting. I can even remember at which corner of the room
>
On Wed, Jan 13, 2021 at 01:27:21AM +, José Abílio Matos wrote:
> What I am proposing is to change to a saner and more predictable model,
> either
> the semantic version or the scheme used by several gnu projects, like at
> least
> gcc and octave.
I hope my memory serves me well, but the
On Wednesday, January 13, 2021 9:48:58 AM WET Jean-Marc Lasgouttes wrote:
> I do not really like this. I find it very useful to add weird character
> in a version string to indicate that the version is not a regular one.
>
> JMarc
This is what I call the "Paris Syndrome", a mild form of the
Le 13/01/2021 à 02:27, José Abílio Matos a écrit :
The development version, unreleased version is 3.0.0.
As soon as the first test version is released it gets the 3.0.1, the next one
is 3.0.2 and so on.
When the release candidates stage is over and a stable version is released as
LyX 3.1.
If a
On Monday, January 11, 2021 10:58:48 PM WET Joel Kulesza wrote:
> Regarding semantic versioning: I feel like LyX already (arguably) uses that.
> The argument I imagine: it's not clear what prompted moving from version
> 1->2,
What is the rationale of the number change?
I have been bugging the
Le 12/01/2021 à 11:00, Pavel Sanda a écrit :
- I prefer to stay with single digits as long as possible because it's
easier to remember/communicate them. The moment the version numbers
go beyond 10, you tend to lose track of versions (experience with
firefox-like scheme).
Firefox
On Mon, Jan 11, 2021 at 03:58:48PM -0700, Joel Kulesza wrote:
> So, this is effectively how things operate now except collapsing the fourth
> entry into the third. Once a breaking change occurs, then the jump would
> be made from 2->3.
I agree. If the 4th number is too disturbing collapsing it
On Mon, Jan 11, 2021 at 08:59:55PM +, José Abílio Matos wrote:
> Since we our release schedule is every two years this will keep us in low
> numbers for a long time.
>
> What do you think?
Not surprisingly, I'd propose to stay where we are.
The reasons are two:
- I prefer to stay with
Am Mo., 11. Jan. 2021 um 23:59 Uhr schrieb Joel Kulesza :
> Regarding semantic versioning: I feel like LyX already (arguably) uses
> that. The argument I imagine: it's not clear what prompted moving from
> version 1->2, but a Python-based conversion script manages forward/backward
>
On Mon, Jan 11, 2021 at 2:18 PM Richard Kimberly Heck
wrote:
> On 1/11/21 3:59 PM, José Abílio Matos wrote:
>
> Today in the virtual meeting we discussed several of the issues regarding
> the next major version for the stable release.
>
> I am proposing here to change to a Semantic Versioning
On Mon, 11 Jan 2021 at 22:36, Jean-Marc Lasgouttes
wrote:
> Le 11/01/2021 à 22:30, Thibaut Cuvelier a écrit :
> > The basic principle of semantic versioning is based on the notion of
> > public API. What is the public API of LyX?
>
> The file format, layout file format and pref file format.
Le 11/01/2021 à 22:30, Thibaut Cuvelier a écrit :
The basic principle of semantic versioning is based on the notion of
public API. What is the public API of LyX?
The file format, layout file format and pref file format. These are
stable across stable versions.
JMarc
--
lyx-devel mailing
On Mon, 11 Jan 2021 at 22:00, José Abílio Matos wrote:
> Today in the virtual meeting we discussed several of the issues regarding
> the next major version for the stable release.
>
> I am proposing here to change to a Semantic Versioning scheme. This can is
> best described here:
>
>
On Monday, January 11, 2021 9:06:27 PM WET Jean-Marc Lasgouttes wrote:
> I would prefer to ignore the last 0 be default, since the sub-releases
> are rare.
>
> Thus: 3.0, 3.1, 3.2, 3.2.1
>
> I do not like extra numbers that almost never move.
>
> And it makes parsing of version number more
On 1/11/21 3:59 PM, José Abílio Matos wrote:
Today in the virtual meeting we discussed several of the issues
regarding the next major version for the stable release.
I am proposing here to change to a Semantic Versioning scheme. This
can is best described here:
https://semver.org/
Le 11/01/2021 à 21:59, José Abílio Matos a écrit :
Today in the virtual meeting we discussed several of the issues
regarding the next major version for the stable release.
I am proposing here to change to a Semantic Versioning scheme. This can
is best described here:
https://semver.org/
Today in the virtual meeting we discussed several of the issues regarding the
next major version for the stable release.
I am proposing here to change to a Semantic Versioning scheme. This can is
best described here:
https://semver.org/
So I am proposing for the next version to be 3.0.0.
The
28 matches
Mail list logo
