Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Reuben Thomas]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

     http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.
------------------------------------------------------------------------

It would be great if it were possible to install stable org-mode
versions from GNU ELPA or MELPA Stable. At present, one has to choose
between installing bleeding-edge versions simply, or stable versions
built by hand.

(I am a bit surprised I can’t find anything about this in the mailing
list archives, so do forgive me if I’ve overlooked previous discussion.)

Emacs  : GNU Emacs 25.1.50.9 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2016-10-15
Package: Org-mode version 8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)
-- 
http://rrt.sc3d.org/

Re: Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Josiah Schwab]

Hi Reuben,

> It would be great if it were possible to install stable org-mode
> versions from GNU ELPA or MELPA Stable. At present, one has to choose
> between installing bleeding-edge versions simply, or stable versions
> built by hand.
>
> (I am a bit surprised I can’t find anything about this in the mailing
> list archives, so do forgive me if I’ve overlooked previous discussion.)

The version on GNU ELPA (http://elpa.gnu.org/packages/org.html), which
is labeled org-20161024, is org-git-version 8.3.6-7-g4d7d52-elpa.

I believe that indicates that it is the latest version from the stable
maint branch, not a version from the unstable master branch (which is at
8.3.6-1264-g21932c right now).

Hope that helps,
Josiah

Re: Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]

On 30 October 2016 at 23:57, Josiah Schwab <jschwab@gmail.com> wrote:

> Hi Reuben,
>
> > It would be great if it were possible to install stable org-mode
> > versions from GNU ELPA or MELPA Stable. At present, one has to choose
> > between installing bleeding-edge versions simply, or stable versions
> > built by hand.
> >
> > (I am a bit surprised I can’t find anything about this in the mailing
> > list archives, so do forgive me if I’ve overlooked previous discussion.)
>
> The version on GNU ELPA (http://elpa.gnu.org/packages/org.html), which
> is labeled org-20161024, is org-git-version 8.3.6-7-g4d7d52-elpa.
>
> I believe that indicates that it is the latest version from the stable
> maint branch, not a version from the unstable master branch (which is at
> 8.3.6-1264-g21932c right now).
>

​That's great! However, is a cut of the release branch as good as an actual
release?

Thought experiment: if it is good enough, surely the web site should
point users to this installation method for the stable version? I can't
imagine there are many users who would prefer to compile from source rather
than just use package-install!
​ Also, the version should be the git tag (so that the version number is
clearly visible), rather than the current "YYYYMMDD" format, which looks
like a development snapshot.

​If the org-mode maintainers do *not* consider these release branch
snapshots to be as good as actual releases, then I would repeat my request
for stable releases to be available on GNU ELPA or MELPA Stable.

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 2730 bytes --]

Re: Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Nicolas Goaziou]

Hello,

Reuben Thomas <rrt@sc3d.org> writes:

> ​That's great! However, is a cut of the release branch as good as an actual
> release?

It is better, since it contains more bugfixes than last release without
adding new features.

However, I think we should make more frequent bugfix releases. We may
even automate such releases, e.g., one week after the last unreleased
bugfix in the branch. I don't do releases however, so this may just be
a weird idea.

Bastien, is it even possible?

> Thought experiment: if it is good enough, surely the web site should
> point users to this installation method for the stable version?

Isn't it the case already? From the first page I see

  M-x list-packages RET (see Org ELPA)

  Daily snapshots: tar.gz or zip

> I can't imagine there are many users who would prefer to compile from
> source rather than just use package-install!

I don't think we force users to use development version (even though it
is appreciated, particularly close to a major release). OTOH, being able
to browse source code is very important so the "git clone" command and
the "cgit" link also belong to the first page.

> ​ Also, the version should be the git tag (so that the version number is
> clearly visible), rather than the current "YYYYMMDD" format, which looks
> like a development snapshot.

We need to tell the difference between a release and a cut from the
maint branch. 

Also, I'd rather have monotonic version tags, so 8.3.6.whatever is not
really an option. Maybe 8.3.YYYMMDD... and we drop manual bugfix
releases altogether.


Regards,

-- 
Nicolas Goaziou

Re: Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Achim Gratz]

Nicolas Goaziou writes:
> However, I think we should make more frequent bugfix releases. We may
> even automate such releases, e.g., one week after the last unreleased
> bugfix in the branch. I don't do releases however, so this may just be
> a weird idea.

We already have that, it's the Org package on GNU ELPA.  There's a new
release each monday, fully automated.

> Also, I'd rather have monotonic version tags, so 8.3.6.whatever is not
> really an option. Maybe 8.3.YYYMMDD... and we drop manual bugfix
> releases altogether.

No, the reason for versioning Org on ELPA in that way is how package.el
interprets version numbers.  You'll get a version string you can
correlate to the Git repo from org-version.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> Nicolas Goaziou writes:
>> However, I think we should make more frequent bugfix releases. We may
>> even automate such releases, e.g., one week after the last unreleased
>> bugfix in the branch. I don't do releases however, so this may just be
>> a weird idea.
>
> We already have that, it's the Org package on GNU ELPA.  There's a new
> release each monday, fully automated.

This is not exactly what I'm suggesting, although the mechanism involved
is probably the same.

I'm suggesting to do a "real release", i.e., with a reassuring version
number (Org 8.3.7, Org 8.3.8). 

Also, the rule I suggest is different: "one week after last unreleased
bugfix" vs "next monday after first unreleased bugfix". One major issue
with the current rule is, e.g., when you introduce a toxic bugfix on
a gloomy Sunday.


Regards,

-- 
Nicolas Goaziou

Re: Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]

On 31 October 2016 at 14:56, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

> Hello,
>
> Reuben Thomas <rrt@sc3d.org> writes:
>
> > ​That's great! However, is a cut of the release branch as good as an
> actual
> > release?
>
> It is better, since it contains more bugfixes than last release without
> adding new features.
>

​That's good to know.​

> Thought experiment: if it is good enough, surely the web site should
> > point users to this installation method for the stable version?
>
> Isn't it the case already? From the first page I see
>
>   M-x list-packages RET (see Org ELPA)
>
>   Daily snapshots: tar.gz or zip
>

​The web page is quite clear. Under "Download and install" you can get
"Stable version" (only from source), or "Development version" (cgit or M_x
list-packages RET), or "Daily snapshots".​

In other words, it looks as though the Org ELPA version is a development
version. The linked page does nothing to counter this impression.

I suggest that the "M-x list-packages RET" part be moved up the page to
"Stable version"; it should say something like:

"Stable version: M-x list-packages RET (see Org ELPA; includes fixes since
last release), or tar.gz or zip (release notes).

Ideally there would be up-to-date release notes for the ELPA version, so
that users can see which bugs are fixed. This should be easy if there is a
partially-completed release notes file in preparation for the next release.

In other words, the ELPA method should be highlighted as the preferred
method of installation, and it should be made obvious that it's stable
(this is why I think it's important to change the version of the ELPA
package to contain the version number; by the way, considering it as a
semver version number, it already is monotonic).

Being able to install org-mode stable from ELPA is something I've wanted
for years without realising it is already available! I bet I'm not the only
one…

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3712 bytes --]

Re: Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Bastien Guerry]

Hi all,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> However, I think we should make more frequent bugfix releases. We may
> even automate such releases, e.g., one week after the last unreleased
> bugfix in the branch. I don't do releases however, so this may just be
> a weird idea.
>
> Bastien, is it even possible?

We could simply have daily snapshot of the maint branch in addition to
daily snapshot of the master branch.

For now http://orgmode.org/org-latest.tar.gz is build from the master
branch, but we could also have http://orgmode.org/org-bugfix.tar.gz.

What do you think?

>> Thought experiment: if it is good enough, surely the web site should
>> point users to this installation method for the stable version?
>
> Isn't it the case already? From the first page I see
>
>   M-x list-packages RET (see Org ELPA)
>
>   Daily snapshots: tar.gz or zip
>
>> I can't imagine there are many users who would prefer to compile from
>> source rather than just use package-install!
>
> I don't think we force users to use development version (even though it
> is appreciated, particularly close to a major release). OTOH, being able
> to browse source code is very important so the "git clone" command and
> the "cgit" link also belong to the first page.

In general, the compiled version is not that much faster and bug
reports we get from uncompiled versions are better.  So it's good
to not force users to use a compiled version IMHO.

>> ​ Also, the version should be the git tag (so that the version number is
>> clearly visible), rather than the current "YYYYMMDD" format, which looks
>> like a development snapshot.
>
> We need to tell the difference between a release and a cut from the
> maint branch. 
>
> Also, I'd rather have monotonic version tags, so 8.3.6.whatever is not
> really an option. Maybe 8.3.YYYMMDD... and we drop manual bugfix
> releases altogether.

I'm not sure what is the issue here.

Thanks,

-- 
 Bastien

Re: Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Bastien Guerry]

Hi,

I changed the order of presentation for installation methods on the
website, promoting Org ELPA method.

Thanks,

-- 
 Bastien

Re: Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

On 1 November 2016 at 10:32, Bastien Guerry <bzg@gnu.org> wrote:

> Hi,
>
> I changed the order of presentation for installation methods on the
> website, promoting Org ELPA method.
>

​That's much better, thanks.

However, I still find the first section of the main page rather confusing.

I think there are two main problems:

1. The top heading is "Download and install", but the second half of the
section is a list of links that look like they belong in a different
section (List of features, Manuals and tutorials…).

2. The various types of download are still too mixed up. For normal users,
there is no need to offer anything other than the ELPA method (unless you
think some users still use pre-package.el Emacs?)

Suggested solution:

I suggest that you move these items to the "Documentation and literature"
section: Manuals and tutorials, Worg, History & acknowledgements, Talks,
GSoC.

Remove the heading "Download and install", but instead make the entire list
heading-sized text. The top-most item in the list should be something like:

"Install Org mode from [GNU ELPA]: M-x package-install RET org RET (for the
[bleeding edge], use [Org ELPA]!)"

The bits in square brackets are links, respectively, to GNU ELPA, the
bleeding edge Worg page, and the Org ELPA page.

The rest of the list is then:

Mailing list and goodies
Org tools (outside Emacs)
How to contribute to Org [no question mark!]

The development version info should move to "How to contribute to Org?".

​The link to "More on installing Org mode" can be moved to the developer
documentation.

I think this would make the page much easier to parse, and hence attract
more casual users, as well as saving more experienced users time.

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3883 bytes --]

Re: Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Nicolas Goaziou]

Hello,

Bastien Guerry <bzg@gnu.org> writes:

> We could simply have daily snapshot of the maint branch in addition to
> daily snapshot of the master branch.
>
> For now http://orgmode.org/org-latest.tar.gz is build from the master
> branch, but we could also have http://orgmode.org/org-bugfix.tar.gz.
>
> What do you think?

This is not what I'm suggesting. Let me try to expunge a bit.

I thing we should automate bugfix releases with regular version
numbering scheme, e.g., 8.3.7 release, /as a replacement for/
org-YYYYMMDD releases. Therefore:

1. org-YYYYMMDD could be renamed org-MAJOR-MINOR-BUGFIX# where MAJOR
   MINOR are never modified automatically, and BUGFIX# is (1+ last
   BUGFIX#).

2. Conditions to make a new automated release ought to change. We could
   wait for a full "idle" week after a commit before releasing (IOW,
   wait for one week after a commit but every new commit during that
   period resets the counter). "next Monday" rule has bitten us already.
   The new rule is not perfect either, but is more secure. If one full
   week is too long, we may reduce it to 4 days.

OTOH "org-bugfix.tar.gz" is not monotonic, so it buys us very little.

What do you think?

Regards,

-- 
Nicolas Goaziou

Re: Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Bastien Guerry]

Hi Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> I thing we should automate bugfix releases with regular version
> numbering scheme, e.g., 8.3.7 release, /as a replacement for/
> org-YYYYMMDD releases.

Okay.

> Therefore:
>
> 1. org-YYYYMMDD could be renamed org-MAJOR-MINOR-BUGFIX# where MAJOR
>    MINOR are never modified automatically, and BUGFIX# is (1+ last
>    BUGFIX#).

I'm fine with this.

> 2. Conditions to make a new automated release ought to change. We could
>    wait for a full "idle" week after a commit before releasing (IOW,
>    wait for one week after a commit but every new commit during that
>    period resets the counter). "next Monday" rule has bitten us already.
>    The new rule is not perfect either, but is more secure. If one full
>    week is too long, we may reduce it to 4 days.

I'm fine with the rule you suggest.

> OTOH "org-bugfix.tar.gz" is not monotonic, so it buys us very little.

We just need to have a link that I can put on the website without the
need to edit the website for each minor release.

Best,

-- 
 Bastien

Re: Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Bastien Guerry]

Hi,

Reuben Thomas <rrt@sc3d.org> writes:

> 1. The top heading is "Download and install", but the second half of
> the section is a list of links that look like they belong in a
> different section (List of features, Manuals and tutorials…).

I could not find an elegant solution for this.  I don't have that much
time to dedicate to this, but patches are welcome.

> 2. The various types of download are still too mixed up. For normal
> users, there is no need to offer anything other than the ELPA method
> (unless you think some users still use pre-package.el Emacs?)

I promoted the ELPA version, but I want to allow the download the
archives, as it's still useful, even for normal users.

> I suggest that you move these items to the "Documentation and
> literature" section: Manuals and tutorials, Worg, History &
> acknowledgements, Talks, GSoC.
>
> Remove the heading "Download and install", but instead make the
> entire list heading-sized text. The top-most item in the list should
> be something like:
>
> "Install Org mode from [GNU ELPA]: M-x package-install RET org RET
> (for the [bleeding edge], use [Org ELPA]!)"
>
> The bits in square brackets are links, respectively, to GNU ELPA, the
> bleeding edge Worg page, and the Org ELPA page.
>
> The rest of the list is then:
>
> Mailing list and goodies
> Org tools (outside Emacs)
> How to contribute to Org [no question mark!]
>
> The development version info should move to "How to contribute to
> Org?".

I think the page is fine now -- we can enhance the whole website
at the next big refreshment.

> ​The link to "More on installing Org mode" can be moved to the
> developer documentation.

The links changed -- given that the "Installation instructions" are
often needed, I think it's good to have it here.

> I think this would make the page much easier to parse, and hence
> attract more casual users, as well as saving more experienced users
> time.

Let me know if the current page is at least 90% "good enough" :)

Thanks!

-- 
 Bastien

Re: Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Achim Gratz]

Nicolas Goaziou writes:
> This is not what I'm suggesting. Let me try to expunge a bit.
>
> I thing we should automate bugfix releases with regular version
> numbering scheme, e.g., 8.3.7 release, /as a replacement for/
> org-YYYYMMDD releases. Therefore:

No, we shouldn't.  It's either automatic or a release, it can't be both.
Also, the releases are distinct from the ELPA packages and you seem to
mix up the two.  They are not the same thing.

> 1. org-YYYYMMDD could be renamed org-MAJOR-MINOR-BUGFIX# where MAJOR
>    MINOR are never modified automatically, and BUGFIX# is (1+ last
>    BUGFIX#).

Org's ELPA package has its own versioning scheme and unless package.el
grows some functionality to sanely deal with discontinuities in
versioning, we need to stick to it.

> 2. Conditions to make a new automated release ought to change. We could
>    wait for a full "idle" week after a commit before releasing (IOW,
>    wait for one week after a commit but every new commit during that
>    period resets the counter). "next Monday" rule has bitten us already.
>    The new rule is not perfect either, but is more secure. If one full
>    week is too long, we may reduce it to 4 days.

Again, if you talk about releases, the way to do that is to tag what
should be released, preferrably sign the tag as well.  Whether you roll
the release automatically or script up somthing that picks up new tags
and does it for you is a separate issue.

BTW, if the Monday ELPA package is bad you can always trigger another
release to ELPA manually and don't need to wait for next Monday to have
cron run the release script.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

On 1 November 2016 at 17:01, Bastien Guerry <bzg@gnu.org> wrote:

>
> Let me know if the current page is at least 90% "good enough" :)
>

​You can have your 90% rating now!

Thanks very much for engaging with my criticism to improve things!

-- 
http://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 974 bytes --]

Re: Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> No, we shouldn't.  It's either automatic or a release, it can't be
> both.

I can't see why. We already "release" automatically new packages.

> Also, the releases are distinct from the ELPA packages and you seem to
> mix up the two.  They are not the same thing.

By release, I mean the act of releasing a new version, not the type of
output (tar.gz, ELPA package). 

In any case, I think it is confusing to have ELPA packages differ from
source releases. Installing through ELPA could be made equivalent to
installing latest stable sources, i.e., both output could be generated
at the same time.

It means that bugfix releases should happen more often and ELPA packages
less often.

>> 1. org-YYYYMMDD could be renamed org-MAJOR-MINOR-BUGFIX# where MAJOR
>>    MINOR are never modified automatically, and BUGFIX# is (1+ last
>>    BUGFIX#).
>
> Org's ELPA package has its own versioning scheme and unless package.el
> grows some functionality to sanely deal with discontinuities in
> versioning, we need to stick to it.

It may be. Not providing org-YYYYMMDD versions anymore could be a step
in the direction of replacing them.

In the worst scenario, we can keep them as packages, and still provide
org-X.Y.Z alongside.

>> 2. Conditions to make a new automated release ought to change. We could
>>    wait for a full "idle" week after a commit before releasing (IOW,
>>    wait for one week after a commit but every new commit during that
>>    period resets the counter). "next Monday" rule has bitten us already.
>>    The new rule is not perfect either, but is more secure. If one full
>>    week is too long, we may reduce it to 4 days.
>
> Again, if you talk about releases, the way to do that is to tag what
> should be released, preferrably sign the tag as well.  Whether you roll
> the release automatically or script up somthing that picks up new tags
> and does it for you is a separate issue.

Per above, the script should also generate a new ELPA package.

> BTW, if the Monday ELPA package is bad you can always trigger another
> release to ELPA manually

How?

> and don't need to wait for next Monday to have cron run the release
> script.

This is the opposite of what I'd like to see. Release script should be
run less frequently, not more.

Regards,

-- 
Nicolas Goaziou

Re: Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

[Bastien Guerry]

Reuben Thomas <rrt@sc3d.org> writes:

> Thanks very much for engaging with my criticism to improve things!

Thanks to you for the suggestions!

-- 
 Bastien