[CONCERN] Orgmode version string

[CONCERN] Orgmode version string

[Jambunathan K]

I have every reason to believe that upcoming version of Org would be
tagged as 7.02. Earlier I had argued that version strings be
version-to-list compatible. I would like to reiterate it.

My real concern is that 7.02 would be deemed as equivalent to 7.2
internally by the versioning subsystem and this is likely to clash with
user's point of view. A user would *definitely* assume 7.02 as different
from 7.2 and in all probability swear that former is inferior to the
later.

Please confirm what I am saying by evalling this:

#+begin_src emacs-lisp
  (version-list-= (version-to-list "7.02") (version-to-list "7.2"))
#+end_src

Ignore this mail if it is already taken care of. Needless to say, I have
ELPA-tarballs in mind when I say this.

Jambunathan K.

Re: [CONCERN] Orgmode version string

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> I have every reason to believe that upcoming version of Org would be
> tagged as 7.02. Earlier I had argued that version strings be
> version-to-list compatible. I would like to reiterate it.
>
> My real concern is that 7.02 would be deemed as equivalent to 7.2
> internally by the versioning subsystem and this is likely to clash with
> user's point of view. A user would *definitely* assume 7.02 as different
> from 7.2 and in all probability swear that former is inferior to the
> later.
>
> Please confirm what I am saying by evalling this:
>
> #+begin_src emacs-lisp
>   (version-list-= (version-to-list "7.02") (version-to-list "7.2"))
> #+end_src

I confirm.

> Ignore this mail if it is already taken care of. Needless to say, I have
> ELPA-tarballs in mind when I say this.

Another way is to make Emacs more liberal about version names.

Can you suggest a new default for `version-regexp-alist' so that
7.01 is considered older than 7.10?

(version-list-= (version-to-list "7.02") (version-to-list "7.2"))
being t is not intuitive.

-- 
 Bastien

Re: [CONCERN] Orgmode version string

[Jambunathan K]

Hello Bastien

Bastien <bastien.guerry@wikimedia.fr> writes:

> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> I have every reason to believe that upcoming version of Org would be
>> tagged as 7.02. Earlier I had argued that version strings be
>> version-to-list compatible. I would like to reiterate it.
>>
>> My real concern is that 7.02 would be deemed as equivalent to 7.2
>> internally by the versioning subsystem and this is likely to clash with
>> user's point of view. A user would *definitely* assume 7.02 as different
>> from 7.2 and in all probability swear that former is inferior to the
>> later.
>>
>> Please confirm what I am saying by evalling this:
>>
>> #+begin_src emacs-lisp
>>   (version-list-= (version-to-list "7.02") (version-to-list "7.2"))
>> #+end_src
>
> I confirm.
>
>> Ignore this mail if it is already taken care of. Needless to say, I have
>> ELPA-tarballs in mind when I say this.
>
> Another way is to make Emacs more liberal about version names.
>
> Can you suggest a new default for `version-regexp-alist' so that
> 7.01 is considered older than 7.10?

I don't think I can sell this to emacs-devel with any success. It's not
really worth it.

I think I have made a sensible argument (or atleast recorded my
opinion).  I will leave things at that.

>
> (version-list-= (version-to-list "7.02") (version-to-list "7.2"))
> being t is not intuitive.

Jambunathan K.

Re: [CONCERN] Orgmode version string

[Jambunathan K]

Bastien

> Can you suggest a new default for `version-regexp-alist' so that
> 7.01 is considered older than 7.10?

I assume there is a typo here. Just for the sake of clarification:

(version-list-= (version-to-list "7.01") (version-to-list "7.1")) is t
(version-list-< (version-to-list "7.01") (version-to-list "7.10")) is t

Note that the following difference in above expressions
1. '=' and '<'
2. 7.1 and 7.10

Jambunathan K>

Re: [CONCERN] Orgmode version string

[Carsten Dominik]

Hi Jambunathan,

On Oct 28, 2010, at 2:40 PM, Jambunathan K wrote:

>
> I have every reason to believe that upcoming version of Org would be
> tagged as 7.02. Earlier I had argued that version strings be
> version-to-list compatible. I would like to reiterate it.
>
> My real concern is that 7.02 would be deemed as equivalent to 7.2
> internally by the versioning subsystem and this is likely to clash  
> with
> user's point of view. A user would *definitely* assume 7.02 as  
> different
> from 7.2 and in all probability swear that former is inferior to the
> later.

(version-to-list "7.02")  -> (7 2)
(version-to-list "7.20")  -> (7 20)

so it seems to me that if we keep two-digit numbers, there will be no  
problem at all.

#+begin_src emacs-lisp
  (version-list-= (version-to-list "7.02") (version-to-list "7.20"))
#+end_src

- Carsten

>
> Please confirm what I am saying by evalling this:
>
> #+begin_src emacs-lisp
>  (version-list-= (version-to-list "7.02") (version-to-list "7.2"))
> #+end_src
>
> Ignore this mail if it is already taken care of. Needless to say, I  
> have
> ELPA-tarballs in mind when I say this.
>
> Jambunathan K.
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [CONCERN] Orgmode version string

[Jambunathan K]

Carsten

>
> (version-to-list "7.02")  -> (7 2)
> (version-to-list "7.20")  -> (7 20)
>
> so it seems to me that if we keep two-digit numbers, there will be no
> problem at all.
>
> #+begin_src emacs-lisp
>  (version-list-= (version-to-list "7.02") (version-to-list "7.20"))
> #+end_src

Yes, I agree.

Jambunathan K.

Re: [CONCERN] Orgmode version string

[Jambunathan K]

Carsten

> Hi Jambunathan,
>
> On Oct 28, 2010, at 2:40 PM, Jambunathan K wrote:
>
>>
>> I have every reason to believe that upcoming version of Org would be
>> tagged as 7.02. Earlier I had argued that version strings be
>> version-to-list compatible. I would like to reiterate it.
>>
>> My real concern is that 7.02 would be deemed as equivalent to 7.2
>> internally by the versioning subsystem and this is likely to clash
>> with
>> user's point of view. A user would *definitely* assume 7.02 as
>> different
>> from 7.2 and in all probability swear that former is inferior to the
>> later.
>
> (version-to-list "7.02")  -> (7 2)
> (version-to-list "7.20")  -> (7 20)
>
> so it seems to me that if we keep two-digit numbers, there will be no
> problem at all.
>
> #+begin_src emacs-lisp
>  (version-list-= (version-to-list "7.02") (version-to-list "7.20"))
> #+end_src
>
> - Carsten
>

Now that release-7.02 is out, I am a bit disappointed that a ELPA-tar
named org-7.02.tar would be unusable.

The reason is "7.02" doesn't round-trip well and package manager is
allergic to such a choice. Verify this for yourself.

#+begin_src emacs-lisp
 (package-version-join (version-to-list "7.02"))
#+end_src

If you don't mind sharing, I am curious what made you still go with 7.02
scheme.

Jambunathan K.

>>
>> Please confirm what I am saying by evalling this:
>>
>> #+begin_src emacs-lisp
>>  (version-list-= (version-to-list "7.02") (version-to-list "7.2"))
>> #+end_src
>>
>> Ignore this mail if it is already taken care of. Needless to say, I
>> have
>> ELPA-tarballs in mind when I say this.
>>
>> Jambunathan K.
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Please use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [CONCERN] Orgmode version string

[Carsten Dominik]

On Oct 29, 2010, at 3:06 PM, Jambunathan K wrote:

>
> Carsten
>
>> Hi Jambunathan,
>>
>> On Oct 28, 2010, at 2:40 PM, Jambunathan K wrote:
>>
>>>
>>> I have every reason to believe that upcoming version of Org would be
>>> tagged as 7.02. Earlier I had argued that version strings be
>>> version-to-list compatible. I would like to reiterate it.
>>>
>>> My real concern is that 7.02 would be deemed as equivalent to 7.2
>>> internally by the versioning subsystem and this is likely to clash
>>> with
>>> user's point of view. A user would *definitely* assume 7.02 as
>>> different
>>> from 7.2 and in all probability swear that former is inferior to the
>>> later.
>>
>> (version-to-list "7.02")  -> (7 2)
>> (version-to-list "7.20")  -> (7 20)
>>
>> so it seems to me that if we keep two-digit numbers, there will be no
>> problem at all.
>>
>> #+begin_src emacs-lisp
>> (version-list-= (version-to-list "7.02") (version-to-list "7.20"))
>> #+end_src
>>
>> - Carsten
>>
>
> Now that release-7.02 is out, I am a bit disappointed that a ELPA-tar
> named org-7.02.tar would be unusable.
>
> The reason is "7.02" doesn't round-trip well and package manager is
> allergic to such a choice. Verify this for yourself.
>
> #+begin_src emacs-lisp
> (package-version-join (version-to-list "7.02"))
> #+end_src
>
> If you don't mind sharing, I am curious what made you still go with  
> 7.02
> scheme.

Well, most certainly not because I wanted to disappoint you.
On the contrary, I am really greateful for the ground work
you have laid to make us go with the packaging system.

So the reason must be that I have not read/digested the
numbering thread carefully enough.  What I remember from it
is:

- do not use something like 7.02a, because the letter will defeat
   version number testing
- from our most recent exchange I felt that you agree that
   7.02 will behave correctly when compared with the
   version- functions.  So I actually understood that
   you agreed with me.

The reason why I use 7.02 at all is just because I think it
is pretty when one is expecting 2-digit release numbers.
The release file numbers line up nicely in a directory listing.
Things like this.

Do you have the patience to summarize the arguments for me?
I will go with 7.3 for the next release if this is what is
really needed.

Greetings

- Carsten

>
> Jambunathan K.
>
>>>
>>> Please confirm what I am saying by evalling this:
>>>
>>> #+begin_src emacs-lisp
>>> (version-list-= (version-to-list "7.02") (version-to-list "7.2"))
>>> #+end_src
>>>
>>> Ignore this mail if it is already taken care of. Needless to say, I
>>> have
>>> ELPA-tarballs in mind when I say this.
>>>
>>> Jambunathan K.
>>>
>>> _______________________________________________
>>> Emacs-orgmode mailing list
>>> Please use `Reply All' to send replies to the list.
>>> Emacs-orgmode@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [CONCERN] Orgmode version string

[Bastien]

Hi Jambunathan,

Jambunathan K <kjambunathan@gmail.com> writes:

> Now that release-7.02 is out, I am a bit disappointed that a ELPA-tar
> named org-7.02.tar would be unusable.

Let's fix this by having a conversation with the ELPA maintainers.

Can you start a discussion off-list with me, Carsten, ELPA maintainers
and Chong?

I'm willing to better understand what we have to do and why.

Thanks,

-- 
 Bastien

Re: [CONCERN] Orgmode version string

[Jambunathan K]

Carsten

You haven't misunderstood my arguments at all.

>
> - do not use something like 7.02a, because the letter will defeat
>   version number testing

> - from our most recent exchange I felt that you agree that
>   7.02 will behave correctly when compared with the
>   version- functions.  So I actually understood that
>   you agreed with me.

I thought you would go with 7.20 :-) and I didn't see any problem with
that.

>
> The reason why I use 7.02 at all is just because I think it
> is pretty when one is expecting 2-digit release numbers.
> The release file numbers line up nicely in a directory listing.
> Things like this.
>
> Do you have the patience to summarize the arguments for me?

It is better to avoid a '0' prefix. If you build a org-7.02.tar and try
installing using the package manager, you would know what I mean.

> I will go with 7.3 for the next release if this is what is
> really needed.

It is improper for me to say what version you should use. I am careful
that I wouldn't step in to that territory.

All I can say is that C-h v version-to-list and C-h v
version-regexp-alist are your friends. There is a range of schemes
available and surely one such scheme will suit your tastes.

As for snapshot releases it is better rely on the YYYYMMDD scheme for
packaging. M-x org-version can continue to report git magic numbers in
the version string.

Jambunathan K.