Re: Change LyX release numbering to Semantic Versioning

[José Abílio Matos]

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
> releases, this would be very simple too.

I think that this is not your first remark about prime numbers on release 
numbers. :-)

We follow a green policy and recycle arguments in these threads. :-)

BTW in the same vein I propose to use perfect numbers. :-)

In this case what I meant is that if you see that gcc used was version 11.0 
you know that the series 11 was used. If that is stable or not that is another 
issue.

Using the same analogy do you remember when we had middle odd-numbered 
versions for development and even as stable (following linux scheme at the 
time)?

In that case you really need to search in a website to understand if lyx 2.3.x 
is a stable release or not.
If I am not wrong gnome still follows that scheme (I do not follow the project 
to know what are their plans after gnome 40, their next stable release).

> At least, when a version is 2.99.4 or 2.4.0alpha1, I know it is not a
> regular release. Beat that with your "we all know what it means" system.

Those are not necessarily universal convention.
In the first case armadillo had a series of releases like 9.900.x that were 
stable releases.

Personally I do not like the addition of alpha numeric chars to the releases 
for practical purposes. In particular when I need to parse the release 
versions for building and testing purposes.

In any case this is a detour from the original argument, the original proposal 
is that we should follow a numbering scheme where any stable series receives a 
consecutive new major number every time.

> JMarc

-- 
José Abílio-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Pavel Sanda]

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
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Jean-Marc Lasgouttes]

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 version 5, and it already the seventh release where this
numbering schme is used.

In Fedora Rawhide (to be Fedora 34) the current version of gcc is 11.0.0. That
immediately shows that this is not the stable version. The first stable
version will be 11.1.


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 
releases, this would be very simple too.


At least, when a version is 2.99.4 or 2.4.0alpha1, I know it is not a 
regular release. Beat that with your "we all know what it means" system.


JMarc

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[José Abílio Matos]

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 to expose the reasons why I think that the change is worth.
I think that by now all the arguments have been presented. We should make a 
decision and proceed. :-)
 
> It's not a grave issue to me so if majority decides that we should
> abandon the current versioning scheme I can live with that.
> 
> .. I might fight for LyX-year.minor versioning scheme once we hit 9 though 

That is fair. :-)
On the other hand at that time I will be probably hunted by the year 2038 
problem. :-D

> Pavel


-- 
José Abílio


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[José Abílio Matos]

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 at the developer meeting dev list:  Wed Dec
> 17 00:29:31 2008 : When compiling LyX 2.0svn I get: ... regards Uwe

I stand corrected. :-)

I had searched yesterday in the mailing list archive. There I found a thread 
named "Subversion don't work in 1.7 version".

This induced me in error. It really meant that svn 1.7 was not working with 
the lyx. I read it wrongly, that svn did not work lyx 1.7.

My mistake. :-)
-- 
José Abílio


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Pavel Sanda]

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
> > sporadic bumps to +1 version for unusual events (like unicode, Qt3->Qt4,
> > XML, anniversaries).
> 
> This is a straw argument since 2.4 has two digits. :-)

Yeah, the whole debate is mainly about the decimal point,
allowing us to live in the realm of 1-9 range -- which is
at least for some of us more comfy :)

> Regarding anniversaries they use to happen once a year. :-)

:)

> So instead of theoretical case let us look concretely in the the next release 
> changes https://wiki.lyx.org/LyX/NewInLyX24
> 
> Does this looks like a minor update?

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 :)

It's not a grave issue to me so if majority decides that we should
abandon the current versioning scheme I can live with that.

.. I might fight for LyX-year.minor versioning scheme once we hit 9 though :))

Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[José Abílio Matos]

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,
> XML, anniversaries).

This is a straw argument since 2.4 has two digits. :-)

Regarding anniversaries they use to happen once a year. :-)


The reason why I am insisting on this is that the version number is about 
communicating with our users.
The second part is that then sporadic jumps will never occur because we 
already had the transition to unicode, Qt2, Qt3, Qt4, Qt5 and that was never 
deemed special for a bump and honestly it will never be.
Even if we move to an xml based file format I expected that the conversion 
tools will ensure a smooth transition.
All those reasons are from a developer point of view.

Again IMHO, important as they are, all those aspects that you refer that are 
implementation details.


By hearth, and without looking in to the release notes, I would say that the:
* introduction of modules;
* the beamer interface overhaul that makes it easier to work with slides are 
more important;
* native support of luatex and xetex;
* The native support of fonts and the interface;
* direct support for dark themes.

Those are what for me constitute major changes. Not the fact that lyx 2.3 was 
the first version to support python 3. As a developer I really like that, but 
our purpose is to ensure that this is seamless to the users.


So instead of theoretical case let us look concretely in the the next release 
changes https://wiki.lyx.org/LyX/NewInLyX24

Does this looks like a minor update?

-- 
José Abílio


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Kornel Benko]

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 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 is which unless I have special interest in some bug etc.
> > 
> > So let me see if I understand. You have a problem with LyX 10 but not with 
> > LyX 
> > 2.10 series. Is that correct?
> 
> 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, XML, 
> anniversaries).

+1

> > My other remark is that are not changes that meet the litmus test of being 
> > considered important enough to deserve the major version jump. There has 
> > not 
> > been none in the previous 20 years. If we applied this reasoning we would 
> > start work on the release of LyX 1.11.
> 
> Well, almost yes, we could be talking about 2.1 now and I do not see major 
> problem with that...
> 
> Pavel

Kornel


pgpGxdyXfXXCO.pgp
Description: Digitale Signatur von OpenPGP
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[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 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 is which unless I have special interest in some bug etc.
> 
> So let me see if I understand. You have a problem with LyX 10 but not with 
> LyX 
> 2.10 series. Is that correct?

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, XML, 
anniversaries).

> My other remark is that are not changes that meet the litmus test of being 
> considered important enough to deserve the major version jump. There has not 
> been none in the previous 20 years. If we applied this reasoning we would 
> start work on the release of LyX 1.11.

Well, almost yes, we could be talking about 2.1 now and I do not see major 
problem with that...

Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[José Abílio Matos]

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 is which unless I have special interest in some bug etc.

So let me see if I understand. You have a problem with LyX 10 but not with LyX 
2.10 series. Is that correct?

My other remark is that are not changes that meet the litmus test of being 
considered important enough to deserve the major version jump. There has not 
been none in the previous 20 years. If we applied this reasoning we would 
start work on the release of LyX 1.11.

> Pavel

-- 
José Abílio


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Pavel Sanda]

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 room
> > were you standing when voicing the issue 
> 
> The meeting was on 2008 and the actual change was in 2010. So it was not at 
> all an immediate effect.

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 at the developer meeting
dev list:  Wed Dec 17 00:29:31 2008 : When compiling LyX 2.0svn I get: ... 
regards Uwe

> My concern is also related with communication.
> We should really stress that any stable series is major change from previous.
> And clearly since 1.2 that is true for all of them IMHO.

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 is which unless
I have special interest in some bug etc.

So if we keep the current scheme we can spare +1.0 switches to unusual 
transitions
or symbolic moves. If we move to the proposed scheme we'll lose this option in
some 15 years.

Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[José Abílio Matos]

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
> were you standing when voicing the issue 

The meeting was on 2008 and the actual change was in 2010. So it was not at 
all an immediate effect.

> I added justification for 2.0 as a celebration of anniversary of the project
> in the release notes, but that was secondary to that push and would not
> happen without. Actually I was not even against that particular bump, but
> to use it now as an argument against predictability for yeat another
> unpredictable jump does not look fair 
> 
> Pavel

It was not my intention to picture it like that. Joel asked what was the 
reason for the change from 1.x to 2.y. At the time I said that with so many 
changes like lyx2lyx or unicode support it was more than time to change to a 
new major version.

The reason why I insist in this for so long is that the changes in lyx are not 
additive but multiplicative. All the versions since 1.2 were real major 
versions that deserve their own major version.

My concern is also related with communication.
We should really stress that any stable series is major change from previous.
And clearly since 1.2 that is true for all of them IMHO.

The time scale it is also relevant, releasing a new version every 2-3 years 
contributes to major changes between the successive versions.
If we follow Jean-Marc's analogy with LibreOffice (they are comparable to us 
in terms of solving similar problems) they have point releases but on the 
other hand they release on a periodic basis (~every 6 months).

-- 
José Abílio


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Pavel Sanda]

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 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 were you standing when 
voicing the issue :)

I added justification for 2.0 as a celebration of anniversary of the project in 
the
release notes, but that was secondary to that push and would not happen without.
Actually I was not even against that particular bump, but to use it now as an
argument against predictability for yeat another unpredictable jump does not 
look fair :)

Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[José Abílio Matos]

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 "Stockholm 
Syndrome". :-D

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 version 5, and it already the seventh release where this 
numbering schme is used.

In Fedora Rawhide (to be Fedora 34) the current version of gcc is 11.0.0. That 
immediately shows that this is not the stable version. The first stable 
version will be 11.1.
-- 
José Abílio


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Jean-Marc Lasgouttes]

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 micro release is required then it goes to 3.1.1.
The usual stable releases that we do will be 3.2, 3.3, 3.4...

In short this scheme is similar to the semver scheme with the exception that
releases where the second number is zero are reserved for development/
stabilizing versions.

What I like in this scheme is that there is no need to place other symbols in
releases to convey its meaning.


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

--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[José Abílio Matos]

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 mailing list ever since 0.12. :-)

And that worked because we changed to version 1.0 (Feb 1999).


In the case of what prompt the change from version 1 to 2 you can search in 
the mailing list. The changed occurred mostly at this time
https://marc.info/?l=lyx-devel&m=12651045747&w=2

FWIW this was January-February 2010.

In particular the 1.5 release where we changed to Unicode/UTF-8 it was in a 
sense a fundamental change.

> but a Python-based conversion script manages forward/backward
> compatibility in such a way that I regard the "API" as unchanging with the
> various changes that underpin 2.4.0 (maybe I'm mistaken).  I would imagine
> a change from 2->3 if, for example, the .lyx file migrated irreversibly
> from what it is now to XML.  Otherwise, as JMarc noted once I was already
> composing this, the "API" is pretty stable.

We are, and try very hard to be, backwards compatible, but we are in no way 
forward compatible. I have been very clear since the begin of lyx2lyx we 
should be able to read perfectly what previous versions LyX version wrote.
If for some reason that does not happen we have a bug.
The conversion of the lyx file format to previous releases works on a best 
basis level but there are changes that are impossible to replicate in a 
general way. They do work most of the time but it is impossible to have them 
work correctly every time. The second law of thermodynamics and the arrow of 
the time...


FWIW this is the list of API breaks that we had previously is:

...
0.6.0
0.8.0
0.10.0
0.12.0
1.0.0
1.1.0
1.1.5
1.1.6.0
1.1.6.3
1.2.0
1.3.0
1.4.0
1.5.0
1.6.0
2.0.0
2.1.0
2.2.0
2.3.0

The version that I placed is the first release of the cycle.

lyx2lyx appeared after 1.2 and with it we had a way to make a more regular 
changes.

After that such as it was the first number is irrelevant.

BTW, do you know that at some point the file format was a real number, in the 
bank format?

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.

This is similar to the semantic version with one exception. In order to give 
an example suppose that we decide to follow that scheme an so the next version 
is LyX 3.

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 micro release is required then it goes to 3.1.1.
The usual stable releases that we do will be 3.2, 3.3, 3.4...

In short this scheme is similar to the semver scheme with the exception that 
releases where the second number is zero are reserved for development/
stabilizing versions.

What I like in this scheme is that there is no need to place other symbols in 
releases to convey its meaning.

-- 
José Abílio


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Jean-Marc Lasgouttes]

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 changes its major number on a 6 weeks (maybe 4 weeks now) 
schedule. We change ours every 110 weeks historically. If we go to 3 
now, we will be at 10 in 14 years.


It is more like LibreOffice than Firefox.

But I am not going to argue more than that.
I guess I have to shelve my proposal to rename ourselves to "LyX Office 
Studio", then.


JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Pavel Sanda]

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 into +1 of third
digit looks ok.

Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Pavel Sanda]

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 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). 
  
- People are already used to certain numbering scheme x.y.z where staying
  with y means fileformat is fixed. I don't see that we are really solving
  any problem with new proposal while forcing people to adopt new policies.


Major bump 2.x->3.x is fine either when we reach high x number or when
something unusual happens (e.g. XML transition, switch from Qt back to
xforms, 30 years of LyX etc. :))

Pavel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Jürgen Spitzmüller]

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
> compatibility in such a way that I regard the "API" as unchanging with the
> various changes that underpin 2.4.0 (maybe I'm mistaken).  I would imagine
> a change from 2->3 if, for example, the .lyx file migrated irreversibly
> from what it is now to XML.  Otherwise, as JMarc noted once I was already
> composing this, the "API" is pretty stable.
>
> Taking Jose's semver example, I'd alternatively summarize as:
>
> So I am proposing for the next version to be 2.4.0.
>
> The stable bug fix releases for this series would be 2.4.1, 2.4.2,...
>
> If, for instance, there is a problem in the stable version 2.4.2 then we
> can immediately release version 2.4.3.
>
>
> 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.
>
> Regarding how these numbers might matter to someone: I've had experience
> with organizations that approve software for use based on major version
> number.  So, changing major version number can require re-review for use,
> which inhibits adoption/continued use.  This is not insurmountable, and
> it's a very unique and bizarre concern; however, I did want to raise it as
> an issue and why I'm not too enthusiastic about rapid version number
> changes.  That said, my belief is that numbers are straightforward to count
> and arbitrary anyway, so rapid incrementation doesn't bother me personally.
>

Just for the records, I do not really care as long as the version does not
increase to something bizarre (maybe apply Linus' "no more fingers left to
count" rule).

If we apply Joel's approach, it is well possible that we'll never reach
3.0. At least I hope we won't have changes that are incompatible in the
sense that we cannot convert and revert via lyx2lyx. If this doesn't count,
any major release is such an incompatible change.

Jürgen
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Joel Kulesza]

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 scheme. This can is
> best described here:
>
> https://semver.org/
>
> So I am proposing for the next version to be 3.0.0.
>
> The stable bug fix releases for this series would be 3.1.0, 3.2.0,...
>
> If, for instance, there is a problem in the stable version 3.2.0 then we
> can immediately release version 3.2.1.
>
> Since we our release schedule is every two years this will keep us in low
> numbers for a long time.
>
> What do you think?
>
> I would like to hear from Joel about this. Apparently, these numbers
> matter to some people.
>
> Riki
>
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
compatibility in such a way that I regard the "API" as unchanging with the
various changes that underpin 2.4.0 (maybe I'm mistaken).  I would imagine
a change from 2->3 if, for example, the .lyx file migrated irreversibly
from what it is now to XML.  Otherwise, as JMarc noted once I was already
composing this, the "API" is pretty stable.

Taking Jose's semver example, I'd alternatively summarize as:

So I am proposing for the next version to be 2.4.0.

The stable bug fix releases for this series would be 2.4.1, 2.4.2,...

If, for instance, there is a problem in the stable version 2.4.2 then we
can immediately release version 2.4.3.


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.

Regarding how these numbers might matter to someone: I've had experience
with organizations that approve software for use based on major version
number.  So, changing major version number can require re-review for use,
which inhibits adoption/continued use.  This is not insurmountable, and
it's a very unique and bizarre concern; however, I did want to raise it as
an issue and why I'm not too enthusiastic about rapid version number
changes.  That said, my belief is that numbers are straightforward to count
and arbitrary anyway, so rapid incrementation doesn't bother me personally.

Thank you,
Joel
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Thibaut Cuvelier]

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. These are
> stable across stable versions.
>

Actually, it does make sense! I have no specific opinion on versioning
schemes for LyX, but if you want to switch to semver, I think this should
be explained on the website along with the semver switch.
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Jean-Marc Lasgouttes]

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 list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Thibaut Cuvelier]

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:
>
> https://semver.org/
>
> So I am proposing for the next version to be 3.0.0.
>
> The stable bug fix releases for this series would be 3.1.0, 3.2.0,...
>
> If, for instance, there is a problem in the stable version 3.2.0 then we
> can immediately release version 3.2.1.
>
> Since we our release schedule is every two years this will keep us in low
> numbers for a long time.
>
> What do you think?
>

The basic principle of semantic versioning is based on the notion of public
API. What is the public API of LyX?
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[José Abílio Matos]

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 interesting.
> 
> JMarc

FWIW, personally, I agree with you.
What I described was the semantic versioning scheme.

In rpm, that I know well due to packaging for Fedora, allows the scheme you 
suggest. E.g.

$ rpmdev-vercmp 3.0.10 3.1
3.0.10 < 3.1

-- 
José Abílio-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Richard Kimberly Heck]

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/ 


So I am proposing for the next version to be 3.0.0.


The stable bug fix releases for this series would be 3.1.0, 3.2.0,...


If, for instance, there is a problem in the stable version 3.2.0 then 
we can immediately release version 3.2.1.



Since we our release schedule is every two years this will keep us in 
low numbers for a long time.



What do you think?

I would like to hear from Joel about this. Apparently, these numbers 
matter to some people.


Riki


-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Change LyX release numbering to Semantic Versioning

[Jean-Marc Lasgouttes]

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/ 


So I am proposing for the next version to be 3.0.0.


The stable bug fix releases for this series would be 3.1.0, 3.2.0,...


> If, for instance, there is a problem in the stable version 3.2.0 then we
> can immediately release version 3.2.1.

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 interesting.

JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Change LyX release numbering to Semantic Versioning

[José Abílio Matos]

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 stable bug fix releases for this series would be 3.1.0, 3.2.0,...

If, for instance, there is a problem in the stable version 3.2.0 then we can 
immediately release version 3.2.1.

Since we our release schedule is every two years this will keep us in low 
numbers for a long time.

What do you think?

Best regards,
-- 
José Abílio-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel