* 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/)]
2016-10-31 14:56 ` Nicolas Goaziou
@ 2016-10-31 18:52 ` Achim Gratz
2016-10-31 19:06 ` Nicolas Goaziou
2016-10-31 19:45 ` Reuben Thomas
2016-11-01 10:27 ` Bastien Guerry
2 siblings, 1 reply; 17+ messages in thread
From: Achim Gratz @ 2016-10-31 18:52 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* 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/)]
2016-10-31 18:52 ` Achim Gratz
@ 2016-10-31 19:06 ` Nicolas Goaziou
0 siblings, 0 replies; 17+ messages in thread
From: Nicolas Goaziou @ 2016-10-31 19:06 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* 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/)]
2016-10-31 14:56 ` Nicolas Goaziou
2016-10-31 18:52 ` Achim Gratz
@ 2016-10-31 19:45 ` Reuben Thomas
2016-11-01 10:32 ` Bastien Guerry
2016-11-01 10:27 ` Bastien Guerry
2 siblings, 1 reply; 17+ messages in thread
From: Reuben Thomas @ 2016-10-31 19:45 UTC (permalink / raw)
To: Reuben Thomas, Josiah Schwab, emacs-orgmode@gnu.org,
Bastien Guerry
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* 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/)]
2016-10-31 19:45 ` Reuben Thomas
@ 2016-11-01 10:32 ` Bastien Guerry
2016-11-01 10:59 ` Reuben Thomas
0 siblings, 1 reply; 17+ messages in thread
From: Bastien Guerry @ 2016-11-01 10:32 UTC (permalink / raw)
To: Reuben Thomas; +Cc: Josiah Schwab, emacs-orgmode@gnu.org
Hi,
I changed the order of presentation for installation methods on the
website, promoting Org ELPA method.
Thanks,
--
Bastien
^ permalink raw reply [flat|nested] 17+ messages in thread
* 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/)]
2016-11-01 10:32 ` Bastien Guerry
@ 2016-11-01 10:59 ` Reuben Thomas
2016-11-01 17:01 ` Bastien Guerry
0 siblings, 1 reply; 17+ messages in thread
From: Reuben Thomas @ 2016-11-01 10:59 UTC (permalink / raw)
To: Bastien Guerry; +Cc: Josiah Schwab, emacs-orgmode@gnu.org
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* 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/)]
2016-11-01 10:59 ` Reuben Thomas
@ 2016-11-01 17:01 ` Bastien Guerry
2016-11-01 23:01 ` Reuben Thomas
0 siblings, 1 reply; 17+ messages in thread
From: Bastien Guerry @ 2016-11-01 17:01 UTC (permalink / raw)
To: Reuben Thomas; +Cc: Josiah Schwab, emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* 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/)]
2016-10-31 14:56 ` Nicolas Goaziou
2016-10-31 18:52 ` Achim Gratz
2016-10-31 19:45 ` Reuben Thomas
@ 2016-11-01 10:27 ` Bastien Guerry
2016-11-01 11:08 ` Nicolas Goaziou
2 siblings, 1 reply; 17+ messages in thread
From: Bastien Guerry @ 2016-11-01 10:27 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Josiah Schwab, emacs-orgmode@gnu.org, Reuben Thomas
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* 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/)]
2016-11-01 10:27 ` Bastien Guerry
@ 2016-11-01 11:08 ` Nicolas Goaziou
2016-11-01 15:28 ` Bastien Guerry
2016-11-01 17:33 ` Achim Gratz
0 siblings, 2 replies; 17+ messages in thread
From: Nicolas Goaziou @ 2016-11-01 11:08 UTC (permalink / raw)
To: Bastien Guerry; +Cc: Josiah Schwab, emacs-orgmode@gnu.org, Reuben Thomas
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* 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/)]
2016-11-01 11:08 ` Nicolas Goaziou
@ 2016-11-01 15:28 ` Bastien Guerry
2016-11-01 17:33 ` Achim Gratz
1 sibling, 0 replies; 17+ messages in thread
From: Bastien Guerry @ 2016-11-01 15:28 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Josiah Schwab, emacs-orgmode@gnu.org, Reuben Thomas
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* 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/)]
2016-11-01 11:08 ` Nicolas Goaziou
2016-11-01 15:28 ` Bastien Guerry
@ 2016-11-01 17:33 ` Achim Gratz
2016-11-01 23:43 ` Nicolas Goaziou
1 sibling, 1 reply; 17+ messages in thread
From: Achim Gratz @ 2016-11-01 17:33 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* 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/)]
2016-11-01 17:33 ` Achim Gratz
@ 2016-11-01 23:43 ` Nicolas Goaziou
0 siblings, 0 replies; 17+ messages in thread
From: Nicolas Goaziou @ 2016-11-01 23:43 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 17+ messages in thread