Stable releases

Stable releases

[Scott Randby]

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.

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.

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.

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

Scott Randby

Re: Stable releases

[Ista Zahn]

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
>

Re: Stable releases

[Suvayu Ali]

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.

Re: Stable releases

[Rasmus]

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

Re: Stable releases

[Scott Randby]

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
>

Re: Stable releases

[Nicolas Goaziou]

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

Re: Stable releases

[Peter Salazar]

[-- 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 --]

Re: Stable releases

[Scott Randby]

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

Re: Stable releases

[Rasmus]

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

Re: Stable releases

[Bastien]

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

Re: Stable releases

[Bastien]

Bastien <bzg@gnu.org> writes:

> This is not too late -- can you add a note in etc/ORG-NEWS in maint
> about this change?

Forget about this, I've reintroduced org-latex-with-hyperref.

-- 
 Bastien

Re: Stable releases

[Achim Gratz]

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

Re: Stable releases

[Scott Randby]

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

Re: Stable releases

[Eric S Fraga]

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

Re: Stable releases

[Scott Randby]

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.

>

Re: Stable releases

[Bastien]

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

Re: Stable releases

[Scott Randby]

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,
>

Re: Stable releases

[Russell Adams]

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

Re: Stable releases

[Bastien]

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

Re: Stable releases

[Rasmus]

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

Re: Stable releases

[Bastien]

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

Re: Stable releases

[Thomas S. Dye]

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

Re: Stable releases

[Suvayu Ali]

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.

Re: Stable releases

[Thomas S. Dye]

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

Re: Stable releases

[Achim Gratz]

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

Re: Stable releases

[Thomas S. Dye]

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

Re: Stable releases

[Achim Gratz]

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

Re: Stable releases

[Thomas S. Dye]

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

Re: Stable releases

[Thomas S. Dye]

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

Re: Stable releases

[Achim Gratz]

Thomas S. Dye writes:
> However, the package manager doesn't (yet) recognize this package and
> when I download ob-* packages, org-2015* is also downloaded.

Did you restart Emacs?  The package files need not be byte-compiled (and
shouldn't, IMHO).


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

Re: Stable releases

[Thomas S. Dye]

Achim Gratz <Stromeko@nexgo.de> writes:

> Thomas S. Dye writes:
>> However, the package manager doesn't (yet) recognize this package and
>> when I download ob-* packages, org-2015* is also downloaded.
>
> Did you restart Emacs?  The package files need not be byte-compiled (and
> shouldn't, IMHO).

No, but when I did that just now everything worked as expected.

Many thanks!

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: Stable releases

[Rasmus]

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

Re: Stable releases

[Nicolas Goaziou]

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

Re: Stable releases

[Bastien]

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

Re: Stable releases

[Nicolas Goaziou]

Bastien <bzg@gnu.org> writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> 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.

Done.


Regards,

Re: Stable releases

[Rasmus]

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

Losing trust in Org: stable org-mode releases and unit tests for basic functionality

[Karl Voit]

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

Re: Losing trust in Org: stable org-mode releases and unit tests for basic functionality

[Achim Gratz]

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

Re: Losing trust in Org: stable org-mode releases and unit tests for basic functionality

[Karl Voit]

Hallo Achim!

* Achim Gratz <Stromeko@nexgo.de> wrote:
> 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.

Oh. My fault.

I thought that "maint" is the "unstable" one. However, reading [1] I
learned that I most probably want to try the maint branch. You're
right.

Greetings from Graz, Gratz! [2]

[1] http://orgmode.org/worg/dev/

[2] Oh no, another Euro for the bad-joke-jar ...

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

Re: Losing trust in Org: stable org-mode releases and unit tests for basic functionality

[Marco Wahl]

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

Re: Losing trust in Org: stable org-mode releases and unit tests for basic functionality

[Karl Voit]

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

Re: Losing trust in Org: stable org-mode releases and unit tests for basic functionality

[Marco Wahl]

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