* Re: Stable releases
2015-08-11 17:18 Stable releases Scott Randby
@ 2015-08-11 18:33 ` Ista Zahn
2015-08-11 19:34 ` Suvayu Ali
2015-08-11 20:56 ` Rasmus
` (4 subsequent siblings)
5 siblings, 1 reply; 42+ messages in thread
From: Ista Zahn @ 2015-08-11 18:33 UTC (permalink / raw)
To: Scott Randby; +Cc: emacs-org list
On Tue, Aug 11, 2015 at 1:18 PM, Scott Randby <srandby@gmail.com> wrote:
> While I've used Org's development version in the past, I stopped doing that
> due to my failure to learn how to use git (no time) and other issues. Now, I
> only use the stable releases. But the latest 8.3 release doesn't seem so
> stable to me, so I'd like some clarification about what the Org maintainers
> mean by a stable release. Perhaps this is too vague, so let me explain a
> bit.
[snip]
>
> I guess what I want to know, and maybe there is no answer, is how long
> should I wait before upgrading to a stable release?
One strategy is keeping an eye on the mailing list and waiting for bug
reports to die down before upgrading.
Org is by far the most
> important piece of software I use (I hate it when I can't use Org), and bugs
> (which I know can't be avoided) make it hard, even impossible, for me to get
> my real work done. If there is a way for me to minimize encountering bugs, I
> will appreciate a description of that way.
>
> Scott Randby
>
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: Stable releases
2015-08-11 18:33 ` Ista Zahn
@ 2015-08-11 19:34 ` Suvayu Ali
0 siblings, 0 replies; 42+ messages in thread
From: Suvayu Ali @ 2015-08-11 19:34 UTC (permalink / raw)
To: emacs-orgmode
On Tue, Aug 11, 2015 at 02:33:18PM -0400, Ista Zahn wrote:
> On Tue, Aug 11, 2015 at 1:18 PM, Scott Randby <srandby@gmail.com> wrote:
> >
> > I guess what I want to know, and maybe there is no answer, is how long
> > should I wait before upgrading to a stable release?
>
> One strategy is keeping an eye on the mailing list and waiting for bug
> reports to die down before upgrading.
I would like to add, the community always needs help, and writing code
is not the only way to do that. From your message it seems to me you
have a rather elaborate use for Org. It might serve as a great test
case. If you follow the list regularly, then you could help by testing
the maint branch from time to time (or even master, up to you).
You do not need to know how to use git, you have two options:
- simply download the tarballs from the gitweb interface (see the
"snapshot" links, http://orgmode.org/w/org-mode.git),
- use elpa (either GNU, Org's own)
As for git, I have included the bash function I use to update Org once a
week. If you are interested, feel free to ask me Git questions
off-list.
function update_org() {
pushd ~/build/org-mode # my Org repo and install directory
local dorebase=$(git rev-list origin/master..master|wc -l)
git stash
git checkout master
if [[ $dorebase -gt 0 ]]; then
git pull --rebase --stat
else
git pull
fi
if [ $? == 0 ]; then
echo "+++ Check if merged successfully. +++"
echo "==> Want to continue?"
select yesorno in "Yes" "No"; do
case $yesorno in
Yes)
echo "+++ Building Org-mode $(git branch|egrep '\*') +++";
make compile autoloads info "$@" &> log
[ $? -ne 0 ] && echo "+++ Build failed +++" && break;
echo "+++ Installing Info files +++";
make install-info
break;;
No)
echo "Aborting on user command.";
break;;
*)
echo "==> Choose Yes or No by typing 1 or 2."
esac
done
else
echo "Merge failed, aborting."
fi
popd
}
Hope this helps,
--
Suvayu
Open source is the future. It sets us free.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-11 17:18 Stable releases Scott Randby
2015-08-11 18:33 ` Ista Zahn
@ 2015-08-11 20:56 ` Rasmus
2015-08-12 16:14 ` Scott Randby
2015-08-12 13:39 ` Nicolas Goaziou
` (3 subsequent siblings)
5 siblings, 1 reply; 42+ messages in thread
From: Rasmus @ 2015-08-11 20:56 UTC (permalink / raw)
To: emacs-orgmode
Hi,
The definition of a major release is in README_maintainer:
Main releases are made whenever Org is in a state where the feature
set is consistent and we feel that the features that are implemented
is something we want to support in the future.
AFAIK, Org 8.2.10 ships with Emacs 24.5 and you can use that.
I agree that the changes you mentioned should be in ORG-NEWS.
You can help by testing the master version against your files once in a
while and let us know of breakages.
Rasmus
--
The Kids call him Billy the Saint
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: Stable releases
2015-08-11 20:56 ` Rasmus
@ 2015-08-12 16:14 ` Scott Randby
0 siblings, 0 replies; 42+ messages in thread
From: Scott Randby @ 2015-08-12 16:14 UTC (permalink / raw)
To: emacs-orgmode
On 08/11/2015 04:56 PM, Rasmus wrote:
> Hi,
>
> The definition of a major release is in README_maintainer:
>
> Main releases are made whenever Org is in a state where the feature
> set is consistent and we feel that the features that are implemented
> is something we want to support in the future.
>
> AFAIK, Org 8.2.10 ships with Emacs 24.5 and you can use that.
>
> I agree that the changes you mentioned should be in ORG-NEWS.
>
> You can help by testing the master version against your files once in a
> while and let us know of breakages.
This is very helpful. Thank you.
>
> Rasmus
>
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-11 17:18 Stable releases Scott Randby
2015-08-11 18:33 ` Ista Zahn
2015-08-11 20:56 ` Rasmus
@ 2015-08-12 13:39 ` Nicolas Goaziou
2015-08-12 14:38 ` Peter Salazar
` (2 more replies)
2015-08-12 17:37 ` Achim Gratz
` (2 subsequent siblings)
5 siblings, 3 replies; 42+ messages in thread
From: Nicolas Goaziou @ 2015-08-12 13:39 UTC (permalink / raw)
To: Scott Randby; +Cc: emacs-org list
Hello,
Scott Randby <srandby@gmail.com> writes:
> When I started using 8.3, I discovered that the behavior of commented
> headlines had been changed---a change with which I disagree, a change
> I could not find in the release notes, and one which forces me to
> alter a huge number of files. It seems I missed the discussion about
> commented headlines on the mailing list. This is due to my limited
> knowledge of elisp and programming in general, a gap which makes it
> difficult for me to follow the more technical discussions on the
> mailing list. While it has been explained to me that the change is
> a feature, I consider it to be a serious bug since it is not backwards
> compatible.
I think this change is good. COMMENT status of headlines was muddy
before. The only information about them was the following excerpt (from
Org 8.2.9's manual)
Also entire subtrees starting with the word ‘COMMENT’ will never be
exported.
which can mean many things. You extrapolated this definition to one of
its possible meanings, but your definition, AFAIU, was :noexport:
tags's.
Now there is a clearer definition of a COMMENT headline, and a clear
distinction between COMMENT and :noexport:.
Note that you don't have to alter any of your files. The following
function can do it for you on the fly, before each export. You can also
used it to effectively alter your files automatically for you.
(defun my-comment-to-noexport (backend)
(interactive)
(goto-char (point-min))
(while (re-search-forward "^\\*+.*\\( COMMENT\\)" nil t)
(when (save-match-data (org-in-commented-heading-p t))
(replace-match "" nil nil nil 1)
(org-set-tags-to (cons "noexport" (org-get-tags))))))
(add-hook 'org-export-before-processing-hook #'my-comment-to-noexport)
I admit it could have been notified in ORG-NEWS.
> Another issue I had with 8.3 is the deletion of the
> org-latex-with-hyperref variable, something I could not find in the
> release notes (maybe I missed it). I understand that having Org insert
> \hypersetup{...} details is the most desirable situation, but I fail
> to see the harm in keeping org-latex-with-hyperref for those of us who
> needed it in the past. Yes, I figured out a fix, but this is a fix
> that forces me to stick with an outmoded way of doing things, and so
> I consider this deletion to be a bug.
I'm not sure to understand. What is wrong with setting
`org-latex-hyperref-template' to the empty string?
This change was introduced in Feb 2014. It is a step forward since we
move from an opt-in/opt-out to a full customizable template.
I overlooked the fact that this replacement wasn't signaled in ORG-NEWS,
tho. I will try to be more careful for next release.
> I do understand that all software has bugs, and that everyone working
> on Org is doing so voluntarily (thank you so much for your wonderful
> work). But I was very surprised to find that the evaluation of table
> formulas didn't work in 8.3.1. I could see something like this
> happening in the development version, but it is somewhat mysterious to
> me how such a bug could make its way into a stable release.
I introduced these changes a short time (three days) before release.
I made an announcement[fn:1] in order to warn there could be some
hiccups in that area. It may be obnoxious for you, but no bug was
reported before release.
Another example is the recent columns view bug report[fn:2]. The faulty
commit was pushed 2 months ago. Yet no one during development phase
complained about column view being broken. Even a feature freeze period
wouldn't have helped in that case.
You can't really avoid small glitches after a release.
> I guess what I want to know, and maybe there is no answer, is how long
> should I wait before upgrading to a stable release? Org is by far the
> most important piece of software I use (I hate it when I can't use
> Org), and bugs (which I know can't be avoided) make it hard, even
> impossible, for me to get my real work done. If there is a way for me
> to minimize encountering bugs, I will appreciate a description of that
> way.
I suggest to only do regularly minor updates (e.g. 8.3.1 -> 8.3.2). For
major updates, make sure you have some time to spare for bug reporting.
I think we are usually pretty responsive when it comes to bugs.
Regards,
[fn:1] <http://permalink.gmane.org/gmane.emacs.orgmode/99415>
[fn:2] <http://permalink.gmane.org/gmane.emacs.orgmode/99865>
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: Stable releases
2015-08-12 13:39 ` Nicolas Goaziou
@ 2015-08-12 14:38 ` Peter Salazar
2015-08-12 15:57 ` Scott Randby
2015-08-18 16:44 ` Bastien
2 siblings, 0 replies; 42+ messages in thread
From: Peter Salazar @ 2015-08-12 14:38 UTC (permalink / raw)
To: Scott Randby, emacs-org list
[-- Attachment #1: Type: text/plain, Size: 5019 bytes --]
Here here. I agree that the new clarified COMMENT vs. :noexport:
functionality makes more sense. And thanks to Nicolas and everyone else for
their amazing work.
On Wed, Aug 12, 2015 at 9:39 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
wrote:
> Hello,
>
> Scott Randby <srandby@gmail.com> writes:
>
> > When I started using 8.3, I discovered that the behavior of commented
> > headlines had been changed---a change with which I disagree, a change
> > I could not find in the release notes, and one which forces me to
> > alter a huge number of files. It seems I missed the discussion about
> > commented headlines on the mailing list. This is due to my limited
> > knowledge of elisp and programming in general, a gap which makes it
> > difficult for me to follow the more technical discussions on the
> > mailing list. While it has been explained to me that the change is
> > a feature, I consider it to be a serious bug since it is not backwards
> > compatible.
>
> I think this change is good. COMMENT status of headlines was muddy
> before. The only information about them was the following excerpt (from
> Org 8.2.9's manual)
>
> Also entire subtrees starting with the word ‘COMMENT’ will never be
> exported.
>
> which can mean many things. You extrapolated this definition to one of
> its possible meanings, but your definition, AFAIU, was :noexport:
> tags's.
>
> Now there is a clearer definition of a COMMENT headline, and a clear
> distinction between COMMENT and :noexport:.
>
> Note that you don't have to alter any of your files. The following
> function can do it for you on the fly, before each export. You can also
> used it to effectively alter your files automatically for you.
>
> (defun my-comment-to-noexport (backend)
> (interactive)
> (goto-char (point-min))
> (while (re-search-forward "^\\*+.*\\( COMMENT\\)" nil t)
> (when (save-match-data (org-in-commented-heading-p t))
> (replace-match "" nil nil nil 1)
> (org-set-tags-to (cons "noexport" (org-get-tags))))))
>
> (add-hook 'org-export-before-processing-hook #'my-comment-to-noexport)
>
> I admit it could have been notified in ORG-NEWS.
>
> > Another issue I had with 8.3 is the deletion of the
> > org-latex-with-hyperref variable, something I could not find in the
> > release notes (maybe I missed it). I understand that having Org insert
> > \hypersetup{...} details is the most desirable situation, but I fail
> > to see the harm in keeping org-latex-with-hyperref for those of us who
> > needed it in the past. Yes, I figured out a fix, but this is a fix
> > that forces me to stick with an outmoded way of doing things, and so
> > I consider this deletion to be a bug.
>
> I'm not sure to understand. What is wrong with setting
> `org-latex-hyperref-template' to the empty string?
>
> This change was introduced in Feb 2014. It is a step forward since we
> move from an opt-in/opt-out to a full customizable template.
>
> I overlooked the fact that this replacement wasn't signaled in ORG-NEWS,
> tho. I will try to be more careful for next release.
>
> > I do understand that all software has bugs, and that everyone working
> > on Org is doing so voluntarily (thank you so much for your wonderful
> > work). But I was very surprised to find that the evaluation of table
> > formulas didn't work in 8.3.1. I could see something like this
> > happening in the development version, but it is somewhat mysterious to
> > me how such a bug could make its way into a stable release.
>
> I introduced these changes a short time (three days) before release.
> I made an announcement[fn:1] in order to warn there could be some
> hiccups in that area. It may be obnoxious for you, but no bug was
> reported before release.
>
> Another example is the recent columns view bug report[fn:2]. The faulty
> commit was pushed 2 months ago. Yet no one during development phase
> complained about column view being broken. Even a feature freeze period
> wouldn't have helped in that case.
>
> You can't really avoid small glitches after a release.
>
> > I guess what I want to know, and maybe there is no answer, is how long
> > should I wait before upgrading to a stable release? Org is by far the
> > most important piece of software I use (I hate it when I can't use
> > Org), and bugs (which I know can't be avoided) make it hard, even
> > impossible, for me to get my real work done. If there is a way for me
> > to minimize encountering bugs, I will appreciate a description of that
> > way.
>
> I suggest to only do regularly minor updates (e.g. 8.3.1 -> 8.3.2). For
> major updates, make sure you have some time to spare for bug reporting.
> I think we are usually pretty responsive when it comes to bugs.
>
>
> Regards,
>
> [fn:1] <http://permalink.gmane.org/gmane.emacs.orgmode/99415>
>
> [fn:2] <http://permalink.gmane.org/gmane.emacs.orgmode/99865>
>
> --
> Nicolas Goaziou
>
>
[-- Attachment #2: Type: text/html, Size: 6056 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: Stable releases
2015-08-12 13:39 ` Nicolas Goaziou
2015-08-12 14:38 ` Peter Salazar
@ 2015-08-12 15:57 ` Scott Randby
2015-08-12 22:56 ` Rasmus
2015-08-18 16:44 ` Bastien
2 siblings, 1 reply; 42+ messages in thread
From: Scott Randby @ 2015-08-12 15:57 UTC (permalink / raw)
To: emacs-org list
On 08/12/2015 09:39 AM, Nicolas Goaziou wrote:
> Hello,
>
> Scott Randby <srandby@gmail.com> writes:
>
>> When I started using 8.3, I discovered that the behavior of commented
>> headlines had been changed---a change with which I disagree, a change
>> I could not find in the release notes, and one which forces me to
>> alter a huge number of files. It seems I missed the discussion about
>> commented headlines on the mailing list. This is due to my limited
>> knowledge of elisp and programming in general, a gap which makes it
>> difficult for me to follow the more technical discussions on the
>> mailing list. While it has been explained to me that the change is
>> a feature, I consider it to be a serious bug since it is not backwards
>> compatible.
>
> I think this change is good. COMMENT status of headlines was muddy
> before. The only information about them was the following excerpt (from
> Org 8.2.9's manual)
>
> Also entire subtrees starting with the word ‘COMMENT’ will never be
> exported.
>
> which can mean many things. You extrapolated this definition to one of
> its possible meanings, but your definition, AFAIU, was :noexport:
> tags's.
>
> Now there is a clearer definition of a COMMENT headline, and a clear
> distinction between COMMENT and :noexport:.
>
> Note that you don't have to alter any of your files. The following
> function can do it for you on the fly, before each export. You can also
> used it to effectively alter your files automatically for you.
>
> (defun my-comment-to-noexport (backend)
> (interactive)
> (goto-char (point-min))
> (while (re-search-forward "^\\*+.*\\( COMMENT\\)" nil t)
> (when (save-match-data (org-in-commented-heading-p t))
> (replace-match "" nil nil nil 1)
> (org-set-tags-to (cons "noexport" (org-get-tags))))))
>
> (add-hook 'org-export-before-processing-hook #'my-comment-to-noexport)
This function won't work for me because I use COMMENT in two different
ways. I didn't extrapolate the meaning of COMMENT, I copied its various
uses from files that other people have posted in various places. It is
more flexible for COMMENT to mean various things than it is for it to be
pigeonholed to one narrow function. COMMENT wasn't broken until 8.3.
>
> I admit it could have been notified in ORG-NEWS.
>
>> Another issue I had with 8.3 is the deletion of the
>> org-latex-with-hyperref variable, something I could not find in the
>> release notes (maybe I missed it). I understand that having Org insert
>> \hypersetup{...} details is the most desirable situation, but I fail
>> to see the harm in keeping org-latex-with-hyperref for those of us who
>> needed it in the past. Yes, I figured out a fix, but this is a fix
>> that forces me to stick with an outmoded way of doing things, and so
>> I consider this deletion to be a bug.
>
> I'm not sure to understand. What is wrong with setting
> `org-latex-hyperref-template' to the empty string?
I don't understand what is wrong with keeping org-latex-with-hyperref.
It is easy enough for me to set the variable locally for old files while
I can use the default \hypersetup{...} for new files. Making
org-latex-hyperref-template an empty string means I cannot use the
built-in default template.
>
> This change was introduced in Feb 2014. It is a step forward since we
> move from an opt-in/opt-out to a full customizable template.
I'm not sure why I didn't notice a problem before 8.3. Perhaps it is due
to my irregular updating.
>
> I overlooked the fact that this replacement wasn't signaled in ORG-NEWS,
> tho. I will try to be more careful for next release.
>
>> I do understand that all software has bugs, and that everyone working
>> on Org is doing so voluntarily (thank you so much for your wonderful
>> work). But I was very surprised to find that the evaluation of table
>> formulas didn't work in 8.3.1. I could see something like this
>> happening in the development version, but it is somewhat mysterious to
>> me how such a bug could make its way into a stable release.
>
> I introduced these changes a short time (three days) before release.
> I made an announcement[fn:1] in order to warn there could be some
> hiccups in that area. It may be obnoxious for you, but no bug was
> reported before release.
I don't consider the bug to be obnoxious, I'm just trying to understand
what is meant by a stable release.
>
> Another example is the recent columns view bug report[fn:2]. The faulty
> commit was pushed 2 months ago. Yet no one during development phase
> complained about column view being broken. Even a feature freeze period
> wouldn't have helped in that case.
>
> You can't really avoid small glitches after a release.
Yes, I understand.
>
>> I guess what I want to know, and maybe there is no answer, is how long
>> should I wait before upgrading to a stable release? Org is by far the
>> most important piece of software I use (I hate it when I can't use
>> Org), and bugs (which I know can't be avoided) make it hard, even
>> impossible, for me to get my real work done. If there is a way for me
>> to minimize encountering bugs, I will appreciate a description of that
>> way.
>
> I suggest to only do regularly minor updates (e.g. 8.3.1 -> 8.3.2). For
> major updates, make sure you have some time to spare for bug reporting.
> I think we are usually pretty responsive when it comes to bugs.
I've been extremely happy with the quick response to bug reports.
>
>
> Regards,
>
> [fn:1] <http://permalink.gmane.org/gmane.emacs.orgmode/99415>
>
> [fn:2] <http://permalink.gmane.org/gmane.emacs.orgmode/99865>
>
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: Stable releases
2015-08-12 15:57 ` Scott Randby
@ 2015-08-12 22:56 ` Rasmus
0 siblings, 0 replies; 42+ messages in thread
From: Rasmus @ 2015-08-12 22:56 UTC (permalink / raw)
To: emacs-orgmode
Scott Randby <srandby@gmail.com> writes:
> I don't understand what is wrong with keeping
> org-latex-with-hyperref. It is easy enough for me to set the variable
> locally for old files while I can use the default \hypersetup{...} for
> new files. Making org-latex-hyperref-template an empty string means I
> cannot use the built-in default template.
You can use file-variable or BIND to set org-latex-with-hyperref to the
empty string or nil. We could include org-latex-with-hyperref, but I
don't see any advantage in having two ways to disable hyperref setup...
Also, org-latex-with-hyperref does not seem to have ox-publish support,
skimming 8.2.10 briefly.
Still, the ORG-NEWS entry could've been better.
Rasmus
--
Warning: Everything saved will be lost
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-12 13:39 ` Nicolas Goaziou
2015-08-12 14:38 ` Peter Salazar
2015-08-12 15:57 ` Scott Randby
@ 2015-08-18 16:44 ` Bastien
2015-08-18 17:30 ` Bastien
2 siblings, 1 reply; 42+ messages in thread
From: Bastien @ 2015-08-18 16:44 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Scott Randby, emacs-org list
Hi Nicolas,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> I'm not sure to understand. What is wrong with setting
> `org-latex-hyperref-template' to the empty string?
>
> This change was introduced in Feb 2014. It is a step forward since we
> move from an opt-in/opt-out to a full customizable template.
>
> I overlooked the fact that this replacement wasn't signaled in ORG-NEWS,
> tho.
This is not too late -- can you add a note in etc/ORG-NEWS in maint
about this change?
Thanks,
--
Bastien
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-11 17:18 Stable releases Scott Randby
` (2 preceding siblings ...)
2015-08-12 13:39 ` Nicolas Goaziou
@ 2015-08-12 17:37 ` Achim Gratz
2015-08-12 19:06 ` Scott Randby
2015-08-18 17:36 ` Bastien
2016-01-17 10:12 ` Losing trust in Org: stable org-mode releases and unit tests for basic functionality Karl Voit
5 siblings, 1 reply; 42+ messages in thread
From: Achim Gratz @ 2015-08-12 17:37 UTC (permalink / raw)
To: emacs-orgmode
Scott Randby writes:
> While I've used Org's development version in the past, I stopped doing
> that due to my failure to learn how to use git (no time) and other
> issues. Now, I only use the stable releases. But the latest 8.3
> release doesn't seem so stable to me, so I'd like some clarification
> about what the Org maintainers mean by a stable release. Perhaps this
> is too vague, so let me explain a bit.
There are no stable releases, but major and minor ones (see
README_maintainer). Major releases are developed in the master branch
and include backwards-incompatible changes as well as new and removed
features. Minor releases are made from the maint branch and are kept
backwards compatible to the last major release (only bug fixes, no new
features, no feature removal).
> Normally, I wait many months before upgrading Org to a new stable
> release, but when 8.3 was released, I upgraded right away (from
> 8.2.10) since I have a new machine on which I installed Emacs 24.5. I
> read through the release notes for anything that might give me
> problems and didn't see anything.
Since the NEWS file isn't automatically generated, there are some holes
to be expected after two years of development. That's not an excuse,
mind you, and everyone should strive to be more diligent in keeping the
code changes synced up with the documentation.
> I guess what I want to know, and maybe there is no answer, is how long
> should I wait before upgrading to a stable release? Org is by far the
> most important piece of software I use (I hate it when I can't use
> Org), and bugs (which I know can't be avoided) make it hard, even
> impossible, for me to get my real work done. If there is a way for me
> to minimize encountering bugs, I will appreciate a description of that
> way.
As always when it comes to updates, there is the camp that says you
should keep with the flow and make many small changes in doing so and
the other one that says to wait unltil the last moment and then do the
big-bang change of everything. In your case it seems you need to plan
for some conversion time whenever you skip to a new major release. I
don't see why you would skip minor releases though.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: Stable releases
2015-08-12 17:37 ` Achim Gratz
@ 2015-08-12 19:06 ` Scott Randby
2015-08-13 9:32 ` Eric S Fraga
0 siblings, 1 reply; 42+ messages in thread
From: Scott Randby @ 2015-08-12 19:06 UTC (permalink / raw)
To: emacs-orgmode
On 08/12/2015 01:37 PM, Achim Gratz wrote:
> Scott Randby writes:
>> While I've used Org's development version in the past, I stopped doing
>> that due to my failure to learn how to use git (no time) and other
>> issues. Now, I only use the stable releases. But the latest 8.3
>> release doesn't seem so stable to me, so I'd like some clarification
>> about what the Org maintainers mean by a stable release. Perhaps this
>> is too vague, so let me explain a bit.
>
> There are no stable releases, but major and minor ones (see
> README_maintainer). Major releases are developed in the master branch
> and include backwards-incompatible changes as well as new and removed
> features. Minor releases are made from the maint branch and are kept
> backwards compatible to the last major release (only bug fixes, no new
> features, no feature removal).
If there are no stable releases, then maybe the web site should not say:
"Stable version 8.3.1 (Aug. 2015)." Perhaps "stable" should just be
eliminated from that phrase. Certainly, the use of "stable" confused me.
Scott
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-12 19:06 ` Scott Randby
@ 2015-08-13 9:32 ` Eric S Fraga
2015-08-13 13:28 ` Scott Randby
0 siblings, 1 reply; 42+ messages in thread
From: Eric S Fraga @ 2015-08-13 9:32 UTC (permalink / raw)
To: Scott Randby; +Cc: emacs-orgmode
On Wednesday, 12 Aug 2015 at 15:06, Scott Randby wrote:
[...]
> If there are no stable releases, then maybe the web site should not
> say: "Stable version 8.3.1 (Aug. 2015)." Perhaps "stable" should just
> be eliminated from that phrase. Certainly, the use of "stable"
> confused me.
I guess it's a matter of interpretation. The word stable can mean
different things. In this context, it is the opposite of labile and
specifically in comparison with the continually changing git version.
Stable does not unfortunately mean "bug-free" nor does it mean anything
with respect to the previous "stable" version.
--
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.1-34-gb911f1
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-13 9:32 ` Eric S Fraga
@ 2015-08-13 13:28 ` Scott Randby
0 siblings, 0 replies; 42+ messages in thread
From: Scott Randby @ 2015-08-13 13:28 UTC (permalink / raw)
To: emacs-orgmode
On 08/13/2015 05:32 AM, Eric S Fraga wrote:
> On Wednesday, 12 Aug 2015 at 15:06, Scott Randby wrote:
>
> [...]
>
>> If there are no stable releases, then maybe the web site should not
>> say: "Stable version 8.3.1 (Aug. 2015)." Perhaps "stable" should just
>> be eliminated from that phrase. Certainly, the use of "stable"
>> confused me.
>
> I guess it's a matter of interpretation. The word stable can mean
> different things. In this context, it is the opposite of labile and
> specifically in comparison with the continually changing git version.
>
> Stable does not unfortunately mean "bug-free" nor does it mean anything
> with respect to the previous "stable" version.
I never expect any version to be bug free.
>
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-11 17:18 Stable releases Scott Randby
` (3 preceding siblings ...)
2015-08-12 17:37 ` Achim Gratz
@ 2015-08-18 17:36 ` Bastien
2015-08-18 17:52 ` Scott Randby
` (3 more replies)
2016-01-17 10:12 ` Losing trust in Org: stable org-mode releases and unit tests for basic functionality Karl Voit
5 siblings, 4 replies; 42+ messages in thread
From: Bastien @ 2015-08-18 17:36 UTC (permalink / raw)
To: Scott Randby; +Cc: emacs-org list
Hi Scott,
the main reason why 8.3 was not as "stable" as it should have been is
that I've been releasing it too quickly, after having been inactive
way too long.
It's kind of a miracle that Org development could continue without an
active "official" maintainer for so long, and we owe a lot to Nicolas
and other contributors for this.
So all the advice you got is good, but think of 8.3 as a "come back"
release, with problems that are largely due to me not paying attention
enough to all those small details that make a good release.
The cure is to deliver major releases at a steady pace, and I'm sure
having a "release team" will help a lot.
In the meantime, `org-latex-with-hyperref' will be back in 8.3.2 as
I don't see why we needed to remove this option too.
Thanks,
--
Bastien
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: Stable releases
2015-08-18 17:36 ` Bastien
@ 2015-08-18 17:52 ` Scott Randby
2015-08-18 20:40 ` Russell Adams
` (2 subsequent siblings)
3 siblings, 0 replies; 42+ messages in thread
From: Scott Randby @ 2015-08-18 17:52 UTC (permalink / raw)
To: emacs-org list
On 08/18/2015 01:36 PM, Bastien wrote:
> Hi Scott,
>
> the main reason why 8.3 was not as "stable" as it should have been is
> that I've been releasing it too quickly, after having been inactive
> way too long.
>
> It's kind of a miracle that Org development could continue without an
> active "official" maintainer for so long, and we owe a lot to Nicolas
> and other contributors for this.
>
> So all the advice you got is good, but think of 8.3 as a "come back"
> release, with problems that are largely due to me not paying attention
> enough to all those small details that make a good release.
>
> The cure is to deliver major releases at a steady pace, and I'm sure
> having a "release team" will help a lot.
I've learned a lot from the advice I've been given, and I'm now better
equipped to handle updates.
>
> In the meantime, `org-latex-with-hyperref' will be back in 8.3.2 as
> I don't see why we needed to remove this option too.
I appreciate this a great deal. It will make my life easier to have this
variable back in Org.
Scott Randby
>
> Thanks,
>
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: Stable releases
2015-08-18 17:36 ` Bastien
2015-08-18 17:52 ` Scott Randby
@ 2015-08-18 20:40 ` Russell Adams
2015-08-18 22:26 ` Bastien
2015-08-19 20:00 ` Rasmus
2015-08-19 8:51 ` Nicolas Goaziou
2015-08-19 19:57 ` Rasmus
3 siblings, 2 replies; 42+ messages in thread
From: Russell Adams @ 2015-08-18 20:40 UTC (permalink / raw)
To: emacs-orgmode
On Tue, Aug 18, 2015 at 07:36:00PM +0200, Bastien wrote:
> Hi Scott,
>
> the main reason why 8.3 was not as "stable" as it should have been is
> that I've been releasing it too quickly, after having been inactive
> way too long.
>
> It's kind of a miracle that Org development could continue without an
> active "official" maintainer for so long, and we owe a lot to Nicolas
> and other contributors for this.
Bastien,
As a Org user since 2006 I've watched and appreciated how much time
and effort yourself and Carsten have put into maintainership. This
significant commitment brings about the following question:
Is Org large enough that it would benefit from being broken into more
pieces?
For instance a stable core that includes only the major mode itself,
which you continue to maintain. This defines the file syntax and
includes core features which require little to no external programs or
libraries.
Then could you break out the exporters, babel, and many of the other
sub-features into "plugins" that could be maintained separately by
others, and they depend back to the core version?
My impression has been that the core Org functionality has been stable
for quite a while, and the org ecosystem grows by leaps and bounds as
new users expand the incredibly flexible syntax to work for their use
case.
Could we reduce the amount of maintenance to the core if we separate
the rapidly changing plugins to separate projects?
Sorry if this has been hashed before, but I felt it appropriate to
ask.
Thanks.
------------------------------------------------------------------
Russell Adams RLAdams@AdamsInfoServ.com
PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/
Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-18 20:40 ` Russell Adams
@ 2015-08-18 22:26 ` Bastien
2015-08-19 20:00 ` Rasmus
1 sibling, 0 replies; 42+ messages in thread
From: Bastien @ 2015-08-18 22:26 UTC (permalink / raw)
To: Russell Adams; +Cc: emacs-orgmode
Hi Russell,
Russell Adams <RLAdams@AdamsInfoServ.Com> writes:
> Could we reduce the amount of maintenance to the core if we separate
> the rapidly changing plugins to separate projects?
I have a plan to let contrib/* live its own life outside of the core
Org repository. I hope this will encourage a sense of ownership for
those libraries.
But most bug reports and feature requests are against Org's core,
so I'm not sure a modular approach would really alleviate the task.
Of course, maybe this intuition is wrong, and many bug reports are
against non-core features.
In any case, I think we just need to stick to our "low floor / high
ceiling" approach: be as inclusive and welcome as possible, and give
as much freedom as required to regular contributors.
Finally, if I feel like I need donations to dedicate more time to Org,
I won't hesitate to ask for support.
--
Bastien
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-18 20:40 ` Russell Adams
2015-08-18 22:26 ` Bastien
@ 2015-08-19 20:00 ` Rasmus
2015-08-20 23:03 ` Bastien
1 sibling, 1 reply; 42+ messages in thread
From: Rasmus @ 2015-08-19 20:00 UTC (permalink / raw)
To: emacs-orgmode
Russell Adams <RLAdams@AdamsInfoServ.Com> writes:
> On Tue, Aug 18, 2015 at 07:36:00PM +0200, Bastien wrote:
>> Hi Scott,
>>
>
>> the main reason why 8.3 was not as "stable" as it should have been is
>> that I've been releasing it too quickly, after having been inactive
>> way too long.
>>
>> It's kind of a miracle that Org development could continue without an
>> active "official" maintainer for so long, and we owe a lot to Nicolas
>> and other contributors for this.
>
> Bastien,
>
> As a Org user since 2006 I've watched and appreciated how much time
> and effort yourself and Carsten have put into maintainership. This
> significant commitment brings about the following question:
>
> Is Org large enough that it would benefit from being broken into more
> pieces?
>
> For instance a stable core that includes only the major mode itself,
> which you continue to maintain. This defines the file syntax and
> includes core features which require little to no external programs or
> libraries.
>
> Then could you break out the exporters, babel, and many of the other
> sub-features into "plugins" that could be maintained separately by
> others, and they depend back to the core version?
>
> My impression has been that the core Org functionality has been stable
> for quite a while, and the org ecosystem grows by leaps and bounds as
> new users expand the incredibly flexible syntax to work for their use
> case.
It's nice to have "batteries included". This is also the strength of
programming languages such as python, emacs-lisp, and to a lesser extend
R.
One data point: I can absolutely not be bothered using anything that is
not at least in contrib.
Rasmus
--
A clever person solves a problem. A wise person avoids it
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-19 20:00 ` Rasmus
@ 2015-08-20 23:03 ` Bastien
2015-08-20 23:56 ` Thomas S. Dye
2015-08-21 18:37 ` Rasmus
0 siblings, 2 replies; 42+ messages in thread
From: Bastien @ 2015-08-20 23:03 UTC (permalink / raw)
To: Rasmus; +Cc: emacs-orgmode
Hi Rasmus,
Rasmus <rasmus@gmx.us> writes:
> One data point: I can absolutely not be bothered using anything that is
> not at least in contrib.
Just out of curiosity: don't you use the Emacs package system at all?
I used not to use it, but thanks to recent improvements, I find it
quite good now -- and I would not mind using Org packages from there.
--
Bastien
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-20 23:03 ` Bastien
@ 2015-08-20 23:56 ` Thomas S. Dye
2015-08-21 7:21 ` Suvayu Ali
2015-08-21 18:37 ` Rasmus
1 sibling, 1 reply; 42+ messages in thread
From: Thomas S. Dye @ 2015-08-20 23:56 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode, Rasmus
Bastien <bzg@gnu.org> writes:
> Hi Rasmus,
>
> Rasmus <rasmus@gmx.us> writes:
>
>> One data point: I can absolutely not be bothered using anything that is
>> not at least in contrib.
>
> Just out of curiosity: don't you use the Emacs package system at all?
>
> I used not to use it, but thanks to recent improvements, I find it
> quite good now -- and I would not mind using Org packages from there.
The package system appears to be quite popular in the Org mode world.
There are a dozen ob-* languages distributed by the package system
vs. eight in contrib. There are fifteen ox-* exporters available
through the package system vs. eleven in contrib.
Download statistics from Melpa indicate several of the packages are
quite popular. ox-reveal has been downloaded more than 4,000 times, and
ox-pandoc and ox-gfm (Github flavored markup) more than 1,000 times.
The babel languages are less popular, but ob-browser (for html),
ob-ipython, ob-mongo, and ob-sml have all been downloaded more than 300
times.
Melpa has 91 org-* packages. The packages evil-org, org-bullets, and
org-fstree have all been downloaded more than 10,000 times. There are
ten others with more than 1,000 downloads.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-20 23:56 ` Thomas S. Dye
@ 2015-08-21 7:21 ` Suvayu Ali
2015-08-22 17:32 ` Thomas S. Dye
0 siblings, 1 reply; 42+ messages in thread
From: Suvayu Ali @ 2015-08-21 7:21 UTC (permalink / raw)
To: emacs-orgmode
Hi Tom,
On Thu, Aug 20, 2015 at 01:56:43PM -1000, Thomas S. Dye wrote:
>
> Bastien <bzg@gnu.org> writes:
>
> > Hi Rasmus,
> >
> > Rasmus <rasmus@gmx.us> writes:
> >
> >> One data point: I can absolutely not be bothered using anything that is
> >> not at least in contrib.
> >
> > Just out of curiosity: don't you use the Emacs package system at all?
> >
> > I used not to use it, but thanks to recent improvements, I find it
> > quite good now -- and I would not mind using Org packages from there.
>
> The package system appears to be quite popular in the Org mode world.
The summary you provide below is very impressive, thanks for compiling
it. It would be a nice addition to worg, with a date attached to it of
course! It's bound to go stale at some point :-p.
However I would like to point out, the documentation for many of these
extensions is rather spreadout and thin. So I agree with Rasmus, as in,
contrib is much more accessible, but I think it also encourages authors
to contribute documentation on worg (after all it's in the official
repository). That said, I'm not sure why some of the extensions, like
ox-reveal, are _not_ in contrib. AFAIU, it's quite mature.
Cheers,
> There are a dozen ob-* languages distributed by the package system
> vs. eight in contrib. There are fifteen ox-* exporters available
> through the package system vs. eleven in contrib.
>
> Download statistics from Melpa indicate several of the packages are
> quite popular. ox-reveal has been downloaded more than 4,000 times, and
> ox-pandoc and ox-gfm (Github flavored markup) more than 1,000 times.
> The babel languages are less popular, but ob-browser (for html),
> ob-ipython, ob-mongo, and ob-sml have all been downloaded more than 300
> times.
>
> Melpa has 91 org-* packages. The packages evil-org, org-bullets, and
> org-fstree have all been downloaded more than 10,000 times. There are
> ten others with more than 1,000 downloads.
--
Suvayu
Open source is the future. It sets us free.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-21 7:21 ` Suvayu Ali
@ 2015-08-22 17:32 ` Thomas S. Dye
2015-08-22 17:44 ` Achim Gratz
0 siblings, 1 reply; 42+ messages in thread
From: Thomas S. Dye @ 2015-08-22 17:32 UTC (permalink / raw)
To: Suvayu Ali; +Cc: emacs-orgmode
Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
> Hi Tom,
>
> On Thu, Aug 20, 2015 at 01:56:43PM -1000, Thomas S. Dye wrote:
>>
>> Bastien <bzg@gnu.org> writes:
>>
>> > Hi Rasmus,
>> >
>> > Rasmus <rasmus@gmx.us> writes:
>> >
>> >> One data point: I can absolutely not be bothered using anything that is
>> >> not at least in contrib.
>> >
>> > Just out of curiosity: don't you use the Emacs package system at all?
>> >
>> > I used not to use it, but thanks to recent improvements, I find it
>> > quite good now -- and I would not mind using Org packages from there.
>>
>> The package system appears to be quite popular in the Org mode world.
>
> The summary you provide below is very impressive, thanks for compiling
> it. It would be a nice addition to worg, with a date attached to it of
> course! It's bound to go stale at some point :-p.
>
> However I would like to point out, the documentation for many of these
> extensions is rather spreadout and thin. So I agree with Rasmus, as in,
> contrib is much more accessible, but I think it also encourages authors
> to contribute documentation on worg (after all it's in the official
> repository). That said, I'm not sure why some of the extensions, like
> ox-reveal, are _not_ in contrib. AFAIU, it's quite mature.
Rasmus' ranking of org mode sources interested me, so I tried to satisfy
my curiosity is all. I hope you didn't think I was disagreeing with his
decision not to be bothered using Org mode packages. I certainly
understand it. I made the same decision wrt the elpa version of Org
mode after struggling with mixed installations--life is too short!
I do have a technical question that you or someone else on the list
might be able to answer for me. When I downloaded the Babel languages
from melpa just now, the elpa version of Org mode was also downloaded
and installed, even though I didn't ask for it. Why is this? Can it be
disabled? Must the elpa Org mode be installed and activated in order for
the Org mode packages to work?
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-22 17:32 ` Thomas S. Dye
@ 2015-08-22 17:44 ` Achim Gratz
2015-08-22 17:55 ` Thomas S. Dye
0 siblings, 1 reply; 42+ messages in thread
From: Achim Gratz @ 2015-08-22 17:44 UTC (permalink / raw)
To: emacs-orgmode
Thomas S. Dye writes:
> I do have a technical question that you or someone else on the list
> might be able to answer for me. When I downloaded the Babel languages
> from melpa just now, the elpa version of Org mode was also downloaded
> and installed, even though I didn't ask for it. Why is this?
Although you don't say which package you tried, I would guess that the
"org" package is specified as a dependency, likely with some minimum
version.
> Can it be disabled? Must the elpa Org mode be installed and activated
> in order for the Org mode packages to work?
From the point of package manager anything installed from the outside
doesn't exist. You can fake that in various way, for instance by
creating a package directory "org-21991231" and putting an org-pkg.el
with
(define-package "org" "21991231" "Fake Org package for dependency resolution" 'nil)
in it.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-22 17:44 ` Achim Gratz
@ 2015-08-22 17:55 ` Thomas S. Dye
2015-08-22 18:00 ` Achim Gratz
0 siblings, 1 reply; 42+ messages in thread
From: Thomas S. Dye @ 2015-08-22 17:55 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Aloha Achim,
Achim Gratz <Stromeko@nexgo.de> writes:
> Thomas S. Dye writes:
>> I do have a technical question that you or someone else on the list
>> might be able to answer for me. When I downloaded the Babel languages
>> from melpa just now, the elpa version of Org mode was also downloaded
>> and installed, even though I didn't ask for it. Why is this?
>
> Although you don't say which package you tried, I would guess that the
> "org" package is specified as a dependency, likely with some minimum
> version.
I tried the ob-* packages and I'm not sure which one(s) might have
triggered this.
>
>> Can it be disabled? Must the elpa Org mode be installed and activated
>> in order for the Org mode packages to work?
>
> From the point of package manager anything installed from the outside
> doesn't exist. You can fake that in various way, for instance by
> creating a package directory "org-21991231" and putting an org-pkg.el
> with
>
> (define-package "org" "21991231" "Fake Org package for dependency resolution" 'nil)
>
> in it.
Excellent. Thanks! Would it be useful to distribute org-21991231 on
elpa?
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-22 17:55 ` Thomas S. Dye
@ 2015-08-22 18:00 ` Achim Gratz
2015-08-22 18:23 ` Thomas S. Dye
0 siblings, 1 reply; 42+ messages in thread
From: Achim Gratz @ 2015-08-22 18:00 UTC (permalink / raw)
To: emacs-orgmode
Thomas S. Dye writes:
> Excellent. Thanks! Would it be useful to distribute org-21991231 on
> elpa?
No, not at all… Unless you want to make sure that noone ever gets an
update until the next millenium starts.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-22 18:00 ` Achim Gratz
@ 2015-08-22 18:23 ` Thomas S. Dye
2015-08-22 18:53 ` Thomas S. Dye
0 siblings, 1 reply; 42+ messages in thread
From: Thomas S. Dye @ 2015-08-22 18:23 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Achim Gratz <Stromeko@nexgo.de> writes:
> Thomas S. Dye writes:
>> Excellent. Thanks! Would it be useful to distribute org-21991231 on
>> elpa?
>
> No, not at all… Unless you want to make sure that noone ever gets an
> update until the next millenium starts.
No, I don't want that. Thanks for the explanation. I'm satisfied
knowing I won't inadvertently download Org mode from elpa again, at
least until several months after my 247th birthday :)
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-22 18:23 ` Thomas S. Dye
@ 2015-08-22 18:53 ` Thomas S. Dye
2015-08-22 18:57 ` Achim Gratz
0 siblings, 1 reply; 42+ messages in thread
From: Thomas S. Dye @ 2015-08-22 18:53 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Thomas S. Dye <tsd@tsdye.com> writes:
> Achim Gratz <Stromeko@nexgo.de> writes:
>
>> Thomas S. Dye writes:
>>> Excellent. Thanks! Would it be useful to distribute org-21991231 on
>>> elpa?
>>
>> No, not at all… Unless you want to make sure that noone ever gets an
>> update until the next millenium starts.
>
> No, I don't want that. Thanks for the explanation. I'm satisfied
> knowing I won't inadvertently download Org mode from elpa again, at
> least until several months after my 247th birthday :)
Oops, I spoke too soon. I created the org-21991231 folder where all the
other emacs packages are installed, added org-pkg.el with the line you
suggested, and byte-compiled to org-pkg.elc.
However, the package manager doesn't (yet) recognize this package and
when I download ob-* packages, org-2015* is also downloaded.
Also, org-21991231 doesn't show up in the package manager.
Is there a registration step?
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-20 23:03 ` Bastien
2015-08-20 23:56 ` Thomas S. Dye
@ 2015-08-21 18:37 ` Rasmus
1 sibling, 0 replies; 42+ messages in thread
From: Rasmus @ 2015-08-21 18:37 UTC (permalink / raw)
To: emacs-orgmode
Hi,
>> One data point: I can absolutely not be bothered using anything that is
>> not at least in contrib.
>
> Just out of curiosity: don't you use the Emacs package system at all?
At work I cannot use package.el. At home, the search cost associated with
checking out org-random-mode is higher. If I'm lucky I can figure out how
it works on github.
The only org package I use from outside of org-mode.git is org-caldav.
> I used not to use it, but thanks to recent improvements, I find it
> quite good now -- and I would not mind using Org packages from there.
Every package you rely on, that is not in the Emacs tarball is a potential
liability. I believe I have had issues with conflicting company packages
previously.
Rasmus
--
There are known knowns; there are things we know that we know
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-18 17:36 ` Bastien
2015-08-18 17:52 ` Scott Randby
2015-08-18 20:40 ` Russell Adams
@ 2015-08-19 8:51 ` Nicolas Goaziou
2015-08-19 9:36 ` Bastien
2015-08-19 19:57 ` Rasmus
3 siblings, 1 reply; 42+ messages in thread
From: Nicolas Goaziou @ 2015-08-19 8:51 UTC (permalink / raw)
To: Bastien; +Cc: Scott Randby, emacs-org list
Hello,
Bastien <bzg@gnu.org> writes:
> that I've been releasing it too quickly, after having been inactive
> way too long.
I disagree. Most bugs reported were introduced months ago. Waiting more
wouldn't have helped here.
> So all the advice you got is good, but think of 8.3 as a "come back"
> release, with problems that are largely due to me not paying attention
> enough to all those small details that make a good release.
...
> In the meantime, `org-latex-with-hyperref' will be back in 8.3.2 as
> I don't see why we needed to remove this option too.
`org-latex-hyperref-template' is more general that
`org-latex-with-hyperref'. Now, we have two variables which can
contradict each other (e.g., setting with-hyperref to t and
hyperref-template to the empty string). This is not very good, IMO.
At the bare minimum `org-latex-with-hyperref' should be an obsolete
alias for `org-latex-hyperref-template', and the latter should support
nil as a possible value.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-19 8:51 ` Nicolas Goaziou
@ 2015-08-19 9:36 ` Bastien
2015-08-19 14:51 ` Nicolas Goaziou
0 siblings, 1 reply; 42+ messages in thread
From: Bastien @ 2015-08-19 9:36 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Scott Randby, emacs-org list
Hi Nicolas,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> I disagree. Most bugs reported were introduced months ago. Waiting more
> wouldn't have helped here.
s/quickly/hastily
> `org-latex-hyperref-template' is more general that
> `org-latex-with-hyperref'. Now, we have two variables which can
> contradict each other (e.g., setting with-hyperref to t and
> hyperref-template to the empty string). This is not very good, IMO.
>
> At the bare minimum `org-latex-with-hyperref' should be an obsolete
> alias for `org-latex-hyperref-template', and the latter should support
> nil as a possible value.
If you want, please go ahead.
Thanks,
--
Bastien
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Stable releases
2015-08-18 17:36 ` Bastien
` (2 preceding siblings ...)
2015-08-19 8:51 ` Nicolas Goaziou
@ 2015-08-19 19:57 ` Rasmus
3 siblings, 0 replies; 42+ messages in thread
From: Rasmus @ 2015-08-19 19:57 UTC (permalink / raw)
To: emacs-orgmode
Bastien <bzg@gnu.org> writes:
> In the meantime, `org-latex-with-hyperref' will be back in 8.3.2 as
> I don't see why we needed to remove this option too.
Because too many cooks spoil the broth. It's a bad idea to have two
variables controlling the same thing. You can put in nil in template if
you don't want it.
Rasmus
--
There are known knowns; there are things we know that we know
^ permalink raw reply [flat|nested] 42+ messages in thread
* Losing trust in Org: stable org-mode releases and unit tests for basic functionality
2015-08-11 17:18 Stable releases Scott Randby
` (4 preceding siblings ...)
2015-08-18 17:36 ` Bastien
@ 2016-01-17 10:12 ` Karl Voit
2016-01-17 10:30 ` Achim Gratz
2016-01-17 13:41 ` Marco Wahl
5 siblings, 2 replies; 42+ messages in thread
From: Karl Voit @ 2016-01-17 10:12 UTC (permalink / raw)
To: emacs-orgmode
Hi!
I want to re-heat the discussion of last summer about stable
releases[1] of Org-mode:
* Scott Randby <srandby@gmail.com> wrote:
> While I've used Org's development version in the past, I stopped doing
> that due to my failure to learn how to use git (no time) and other
> issues. Now, I only use the stable releases. But the latest 8.3 release
> doesn't seem so stable to me[...]
For Scott (I think) and for me "stable" means: save to use with my
current data without corrupting things or losing features of my
workflows.
I had several occasions where "git pull origin master" ended up in
much work for fixing my large set of Org-mode data.
For example several times, org-todo -> DONE on recurring tasks lead
to DONE and closed tasks.
This is quite evil behavior because I rely heavily on a reliable Org
for currently 1162 open tasks in several dozen files. When such a
bug finds its way to my system and I don't recognize it (which is
highly likely in this case), I lose important tasks and even worse:
I lose my trust in Org-mode.
The most current issue of "recurring tasks get closed"[2] is fixed
(with another scoping issue newly introduced[3]): please don't
discuss this issue or any other concrete bug/issue in this thread.
It's just an example to make my point clear:
What I am trying to raise is a discussion on whether or not there
should be a stable git branch or at east some kind of unit test set
that make sure that really basic functionality doesn't get broken
without being recognized instantly. In my humble opinion, there has
to be some kind of continuous integration tests where breaking
things rings loud whistles.
Unfortunately, I don't have time to follow all the interesting
discussions on the mailing list any more. Does this imply, I can't
use Org-mode any more?
The only alternative I can think of is using the conservative(?)
Org-mode which comes with Emacs from my current Linux distribution.
However, I remember multiple cases where those Org-mode versions
still had some bugs and the recommended solution was "upgrade to
Org-mode git commit abcdef". This is how I started with Org-mode
from git in the first place!
So: what should I do to get reliable Org-mode in future to minimize
the chances of losing tasks or my trust in Org?
[1] http://thread.gmane.org/gmane.emacs.orgmode/99881/
[2] http://thread.gmane.org/gmane.emacs.orgmode/104219
[3] http://thread.gmane.org/gmane.emacs.orgmode/104219/focus=104260
--
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
> get Memacs from https://github.com/novoid/Memacs <
https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: Losing trust in Org: stable org-mode releases and unit tests for basic functionality
2016-01-17 10:12 ` Losing trust in Org: stable org-mode releases and unit tests for basic functionality Karl Voit
@ 2016-01-17 10:30 ` Achim Gratz
2016-01-18 13:47 ` Karl Voit
2016-01-17 13:41 ` Marco Wahl
1 sibling, 1 reply; 42+ messages in thread
From: Achim Gratz @ 2016-01-17 10:30 UTC (permalink / raw)
To: emacs-orgmode
Karl Voit writes:
> I had several occasions where "git pull origin master" ended up in
> much work for fixing my large set of Org-mode data.
That's the development branch which can introduce new features and
remove old ones at any time, you should be on maint if you want
"stable". If you want even more stable, then don't update unless you
hit a bug that is fixed in maint.
> What I am trying to raise is a discussion on whether or not there
> should be a stable git branch or at east some kind of unit test set
> that make sure that really basic functionality doesn't get broken
> without being recognized instantly. In my humble opinion, there has
> to be some kind of continuous integration tests where breaking
> things rings loud whistles.
There already is, it's called "maint". And if any tests fail on your
machine, then the convenience target "up2" doesn't install the resulting
Org, so you never see that broken version.
> Unfortunately, I don't have time to follow all the interesting
> discussions on the mailing list any more. Does this imply, I can't
> use Org-mode any more?
No, but I'd say you shouldn't use the development version of Org and you
shouldn't run Org directly from the Git worktree.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Losing trust in Org: stable org-mode releases and unit tests for basic functionality
2016-01-17 10:12 ` Losing trust in Org: stable org-mode releases and unit tests for basic functionality Karl Voit
2016-01-17 10:30 ` Achim Gratz
@ 2016-01-17 13:41 ` Marco Wahl
2016-01-18 14:06 ` Karl Voit
1 sibling, 1 reply; 42+ messages in thread
From: Marco Wahl @ 2016-01-17 13:41 UTC (permalink / raw)
To: emacs-orgmode
Karl Voit <devnull@Karl-Voit.at> writes:
> So: what should I do to get reliable Org-mode in future to minimize
> the chances of losing tasks or my trust in Org?
I think Achim says the right things.
Further I think you can improve Org's reliability (and your perception
on it) by investing more energy into Org. Obviously you already do
invest energy into Org as your contributions on this list show. You
cold go ahead and start reading Org's code, writing tests, etc. Each
action would give you more confidence with Org.
My 2 ct,
--
Marco Wahl
GPG: 0x49010A040A3AE6F2
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Losing trust in Org: stable org-mode releases and unit tests for basic functionality
2016-01-17 13:41 ` Marco Wahl
@ 2016-01-18 14:06 ` Karl Voit
2016-01-19 9:00 ` Marco Wahl
0 siblings, 1 reply; 42+ messages in thread
From: Karl Voit @ 2016-01-18 14:06 UTC (permalink / raw)
To: emacs-orgmode
Mi Marco!
* Marco Wahl <marcowahlsoft@gmail.com> wrote:
>
> Further I think you can improve Org's reliability (and your perception
> on it) by investing more energy into Org. Obviously you already do
> invest energy into Org as your contributions on this list show. You
> cold go ahead and start reading Org's code, writing tests, etc. Each
> action would give you more confidence with Org.
I can follow your thoughts here.
Unfortunately, my elisp knowledge is still to basic to think of
writing ERT tests for my typical use-cases and add them to
org-mode/testing/list/* :-(
I was not able to even locate a simple "mark a simple recurring todo
as done"-test in the current testset. Is it true, that there is no
such test so far?
--
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
> get Memacs from https://github.com/novoid/Memacs <
https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
^ permalink raw reply [flat|nested] 42+ messages in thread* Re: Losing trust in Org: stable org-mode releases and unit tests for basic functionality
2016-01-18 14:06 ` Karl Voit
@ 2016-01-19 9:00 ` Marco Wahl
0 siblings, 0 replies; 42+ messages in thread
From: Marco Wahl @ 2016-01-19 9:00 UTC (permalink / raw)
To: emacs-orgmode
Hi Karl,
> * Marco Wahl <marcowahlsoft@gmail.com> wrote:
>>
>> Further I think you can improve Org's reliability (and your perception
>> on it) by investing more energy into Org. Obviously you already do
>> invest energy into Org as your contributions on this list show. You
>> cold go ahead and start reading Org's code, writing tests, etc. Each
>> action would give you more confidence with Org.
>
> I can follow your thoughts here.
> Unfortunately, my elisp knowledge is still to basic to think of
> writing ERT tests for my typical use-cases and add them to
> org-mode/testing/list/* :-(
Hopefully you will find time to dig into elisp!
> I was not able to even locate a simple "mark a simple recurring todo
> as done"-test in the current testset. Is it true, that there is no
> such test so far?
I also could not find such test. This means potential for more tests.
Best wishes,
--
Marco Wahl
GPG: 0x49010A040A3AE6F2
^ permalink raw reply [flat|nested] 42+ messages in thread