I believe GNU ELPA should contain the stable release.
Of course, this means we need to have a stable release cycle,
and we should put efforts into that, obviously.
--
Bastien
tftor...@tftorrey.com (T.F. Torrey) writes:
> Aaron Ecay writes:
> ...
>> Exposing new users to the vagaries of the master branch may rather lead
>> to atheism.
>
> This sounds like the foot-shooting argument again. Could one not just
> as easily harm one's foot with the master version from gi
Hello Aaron,
Aaron Ecay writes:
> Hi Terry,
>
> 2015ko martxoak 10an, "T.F. Torrey"-ek idatzi zuen:
>
>> Of the things in your list, I think only the NEWS and Changelog are
>> absent from the master branch in git. Lots of us happily use Org master
>> from git without them every day. Do they re
Hi Terry,
2015ko martxoak 10an, "T.F. Torrey"-ek idatzi zuen:
> Of the things in your list, I think only the NEWS and Changelog are
> absent from the master branch in git. Lots of us happily use Org master
> from git without them every day. Do they really need to be done at
> all?
Many people
Hello Aaron,
Aaron Ecay writes:
>> If the goal is to have the latest and greatest version of Org available via
>> ELPA (for all the reasons some people use ELPA instead of git), there
>> are two obvious options:
>>
>> 1. Org could have a stable release every month or so.
>>
>> 2. The Org server
Achim Gratz writes:
> Richard Y. Kim writes:
>> # server.mk has the elpaplus makefile target
>> echo " include mk/server.mk" >> Makefile
> […]
>> # Undo the change made above
>> git checkout Makefile
>
> You know, local.mk was introduced specifically so you wouldn't have to
> do anything like tha
emac...@gmail.com (Richard Y. Kim) writes:
> tftor...@tftorrey.com (T.F. Torrey) writes:
>
>> I wonder how much effort it would take to copy onto my own machine the
>> scripts on the server that package the git maint version into an ELPA
>> version, and modify them to package master instead. Prob
Steinar Bang writes:
> Isn't this what's MELPA is for?
> http://www.emacswiki.org/emacs/MELPA
MELPA is unable to provide a correctly installable package for Org since
they just pull down the tree and don't do the necessary build steps.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron micr
`package-pinned-packages' seems to allow for user choice here. It is
still easy to muck up one's installation, but that is between the user
and package.el, not any particular package, I believe.
On Tue, Mar 10, 2015 at 6:01 AM, Alexis wrote:
>
> On 2015-03-10T06:21:10+1100, T.F. Torrey said:
>
>
On 2015-03-10T06:21:10+1100, T.F. Torrey
said:
TFT> The biggest obstacle I to this that I see is that developers
tend TFT> to hate the package manager and love git.
This developer appreciates both, and thus particularly appreciates
MELPA as well. :-)
Alexis.
> Nikolai Weibull :
> Would it be of interest to anyone else if the bleeding edge version
> was available via elpa?
Isn't this what's MELPA is for?
http://www.emacswiki.org/emacs/MELPA
Ie. GNU ELPA for the official releases and MELPA for git master HEAD.
Richard Y. Kim writes:
> # server.mk has the elpaplus makefile target
> echo " include mk/server.mk" >> Makefile
[…]
> # Undo the change made above
> git checkout Makefile
You know, local.mk was introduced specifically so you wouldn't have to
do anything like that.
Regards,
Achim.
--
+<[Q+ Matr
tftor...@tftorrey.com (T.F. Torrey) writes:
> I wonder how much effort it would take to copy onto my own machine the
> scripts on the server that package the git maint version into an ELPA
> version, and modify them to package master instead. Probably not much.
The shell script below is what I u
Hi Terry,
2015ko martxoak 9an, "T.F. Torrey"-ek idatzi zuen:
>
> Hello,
>
> Rasmus writes:
>
>> As I think somebody said, the correct "fix" to this problem is more
>> frequent released. I'm sure Bastien would appreciate help with this.
>> Do you want to volunteer?
>
> If the goal is to have the
Achim Gratz writes:
> The version of package manager that people most likely use today always
> choses the latest version from _any_ archive available when you update.
> You can't tell it to consider some archive more authoritative than
> another or that it should stick with whatever source archi
T.F. Torrey writes:
> The package manager can only handle one version of a package *per
> archive*, so instead use one archive per version.
The version of package manager that people most likely use today always
choses the latest version from _any_ archive available when you update.
You can't tell
Hello,
Sebastien Vauban writes:
>> As Grant pointed out, it’s a lot more convenient working inside Emacs
>> for switching between versions and such.
>
> How do you switch between versions in ELPA? IIUC, you only get the
> latest version, and if that one is not right, you're kind of stuck: you
>
Nikolai Weibull wrote:
> On Sat, Mar 7, 2015 at 3:47 PM, Xavier Maillard wrote:
>> Nikolai Weibull writes:
>
>>> Would it be of interest to anyone else if the bleeding edge version
>>> was available via elpa?
>
>> Isn't it already available via M-x package interface ?
>
> No, only the version bas
Hello,
Achim Gratz writes:
> It doesn't get any easier than it already is. Having both a stable and
> an unstable version of Org avilable via ELPA is a non-starter for the
> simple reason that the package manager can't deal with the versioning
> problems this would introduce.
I think this is n
Hello again,
Rasmus writes:
>> I want to collaborate on Org files with my wife and parents,
> ^^^
>
> Do you? It sounds cool!
It's complicated.
I've convinced my parents to begin writing memoir-type books, and my
wife works in non-profit, where good books are always good solution
Hello again,
Achim Gratz writes:
> Rasmus writes:
>> I agree. I have the same problem when I build documents (via CI) on a
>> remote Debian server where I don't want to mess around with anything more
>> than what comes with Emacs by default.
>
> You can use a tarball and the support for manual
Hello,
Rasmus writes:
> As I think somebody said, the correct "fix" to this problem is more
> frequent released. I'm sure Bastien would appreciate help with this.
> Do you want to volunteer?
If the goal is to have the latest and greatest version of Org available via
ELPA (for all the reasons s
Rasmus writes:
>> You can use a tarball and the support for manual builds, described in:
>> http://orgmode.org/worg/dev/org-build-system.html#sec-7
>
> I have no desire to use anything more than what comes with emacs-24-nox on
> this system.
You can download any git commit directly from orgmode.or
Achim Gratz writes:
> Rasmus writes:
>> I agree. I have the same problem when I build documents (via CI) on a
>> remote Debian server where I don't want to mess around with anything more
>> than what comes with Emacs by default.
>
> You can use a tarball and the support for manual builds, descri
Rasmus writes:
> I agree. I have the same problem when I build documents (via CI) on a
> remote Debian server where I don't want to mess around with anything more
> than what comes with Emacs by default.
You can use a tarball and the support for manual builds, described in:
http://orgmode.org/wor
Hi,
tftor...@tftorrey.com (T.F. Torrey) writes:
> I want to collaborate on Org files with my wife and parents,
^^^
Do you? It sounds cool!
> In a real-world situation, I want to collaborate on Org files with my
> wife and parents, and I want to use the current best version of Org
>
A major benefit of an ELPA version of the "bleeding edge" version of
Org is that it enables those of us who run Emacs and Org on machines
where we can not install git (or just do not want to) to have the latest
version of Org nonetheless.
In a real-world situation, I want to collaborate on Org fil
Nikolai Weibull writes:
>> Having both a stable and
>> an unstable version of Org avilable via ELPA is a non-starter for the
>> simple reason that the package manager can't deal with the versioning
>> problems this would introduce.
>
> This could, I assume, and was sort of implied in my original
On Sun, Mar 8, 2015 at 6:59 PM, Achim Gratz wrote:
> Nikolai Weibull writes:
>> Is trying to manage it via git+make oneself less likely to cause
>> incidents?
> There's a bunch of people who seem to manage it just fine.
Did I say otherwise?
Does this preclude making an alternative available, on
Nikolai Weibull writes:
> Is trying to manage it via git+make oneself less likely to cause
> incidents?
There's a bunch of people who seem to manage it just fine.
> From the FAQ:
>
> The master branch of the git repository always contains the bleeding
> edge development code. This is important fo
On Sun, Mar 8, 2015 at 3:17 PM, Aaron Ecay wrote:
> IMO this is a bad idea. The bleeding edge version is expected to be
> somewhat unstable, and exposing it via ELPA will lead to foot-shooting
> incidents.
Is trying to manage it via git+make oneself less likely to cause incidents?
>From the FA
Hi Nikolai,
IMO this is a bad idea. The bleeding edge version is expected to be
somewhat unstable, and exposing it via ELPA will lead to foot-shooting
incidents.
On the other hand, it would be nice to have more regular releases from
master to maint. AFAIK the last one was a year and a half ago
Nikolai Weibull writes:
> On Sat, Mar 7, 2015 at 3:47 PM, Xavier Maillard wrote:
>
>> Nikolai Weibull writes:
>
>>> Would it be of interest to anyone else if the bleeding edge version
>>> was available via elpa?
>
>> Isn't it already available via M-x package interface ?
>
> No, only the versi
2015-03-07 15:36 GMT+01:00 Nikolai Weibull :
>
> Would it be of interest to anyone else if the bleeding edge version
> was available via elpa?
>
I'd greatly appreciate it too !
Cheers,
Nicolas
Nikolai Weibull writes:
> Would it be of interest to anyone else if the bleeding edge version
> was available via elpa?
I would also very much appreciate it.
Terry
--
T.F. Torrey
On Sat, Mar 7, 2015 at 3:47 PM, Xavier Maillard wrote:
> Nikolai Weibull writes:
>> Would it be of interest to anyone else if the bleeding edge version
>> was available via elpa?
> Isn't it already available via M-x package interface ?
No, only the version based on the maint branch is availab
Yes because it would allow us to very easily switch between a stable
and unstable installation using the built-in package infrastructure.
On Sat, Mar 7, 2015 at 8:36 AM, Nikolai Weibull wrote:
> Hi!
>
> Would it be of interest to anyone else if the bleeding edge version
> was available via elpa?
Hi,
Nikolai Weibull writes:
> Would it be of interest to anyone else if the bleeding edge version
> was available via elpa?
Isn't it already available via M-x package interface ? I'd rather use
git (I really do not like the package stuff).
Regards
-- Xavier.
Hi!
Would it be of interest to anyone else if the bleeding edge version
was available via elpa?
39 matches
Mail list logo
