Will no more spacemacs versions be released?

[Compro-Prasad]

There is quite a lot of work done on the develop branch. There are more than 100 issues which have already been fixed in develop. Considering the stability factor, Spacemacs is a beta software/configuration. So, most of the users will always face instabilities given the pace at which packages in Emacs are released through Melpa.

1. Is Spacelpa ready for use?
2. The list of changes is too large. Is it still possible to plan out a release?

Edit: Pdumper point was removed as it has been already merged into Emacs master branch.

[Miciah]

There is quite a lot of work done on the develop branch.

2277 commits at this time. https://github.com/syl20bnr/spacemacs/compare/master...develop

There are more than 100 issues which have already been fixed in develop.

159 at this time. https://github.com/syl20bnr/spacemacs/labels/Fixed%20in%20develop

Considering the stability factor, Spacemacs is a beta software/configuration.

I think the most important question is, Is the develop branch more stable than the master branch? The develop branch fixes a lot of issues; does it introduce regressions?

1. Is Spacelpa ready for use?

Are you concerned about the current open issues? It looks like some of these may be release blockers indeed: https://github.com/syl20bnr/spacemacs/issues?utf8=%E2%9C%93&q=spacelpa+is%3Aopen+-label%3A%22Fixed+in+develop%22

2. Pdumper development in Emacs is at a pause. Is that the reason?

The portable dumper is an experimental feature that is not yet in any GNU Emacs release. I don't think it should have any bearing on release planning at this time.

3. The list of changes is too large. Is it still possible to plan out a release?

The contributing guidelines now specify that contributors should write changelog entries, but that rule has not been stringently enforced, and there is a backlog of work to be done. Can this backlog be farmed out to the community? For example, I would be willing to write release notes for some portion of commits (such as all commits within a particular range or that modify a particular set of layers) or to help with copy editing.

[jvillasante]

I'm also interested on this. Should people switch to develop or will be more releases?

[robbyoconnor]

The develop branch does introduce regressions. For example -- when @syl20bnr went on a bit of a bender with the deferred loading of packages as an example of one instance. Other issues do occasionally pop up. People should not become deluded and think develop is stable -- it's not. It breaks at times -- but usually not for long. it's stable most of the time, but not always.

[Miciah]

Over time, the develop branch is unstable, no question. What I meant to ask is the following: Does the develop branch in its present state introduce any regressions vis-à-vis the master branch?

I know there were a lot of issues surrounding deferred loading and environment variables, but those seem to be resolved modulo some edge cases. Looks like there are issues around Spacelpa still. Anything else?

[robbyoconnor]

Not that I see -- I actually use develop as my daily driver

[martin-liu]

+1

[robbyoconnor]

If you want the latest and greatest -- use develop -- Releases and patch releases are made as-needed if a critical bug is found. master is meant to be immutable and always track the latest release.

I use develop as my daily-driver and it works well. I've had it break only a handful of times -- and it's never broken for long -- we have some pretty dedicated people who are ready to fix and squash any bugs that popup.

[robbyoconnor]

Keep in mind that @syl20bnr could get busy with life but he has people merging PRs and with @Miciah helping to triage issues and squash bugs-- which was a major pain point -- things are at least moving forward.

[jeremyong]

I think at this point, all development should just move to master. I understand that maintainers get busy, but having this much divergence for this long doesn't make sense. It's easier to develop live off HEAD and periodically tag a release to demarcate "stable" points for people who really don't want changes.

edit I've quit spacemacs :( This release process is broken and not enough of a value add relative to just managing things yourself.

[karlicoss]

https://github.com/syl20bnr/spacemacs/issues/11741 perhaps this can be closed, release should be soon!

[Compro-Prasad]

Yeah, this will be closed. Lets have a release first.

[agzam]

I personally switched to develop branch over 3 years ago and never looked back. Ironically it feels more stable because whenever something breaks due to upstream issues of some package and the only way to fix it is to adjust Spacemacs, things get fixed faster in develop.

[Miciah]

whenever something breaks due to upstream issues of some package and the only way to fix it is to adjust Spacemacs, things get fixed faster in develop

I believe Spacelpa is supposed to solve exactly that problem. At the moment, a Spacelpa-related issue, #10438, is the only remaining issue for 0.300: https://github.com/syl20bnr/spacemacs/milestone/7.

(I too prefer using the develop branch though.)

[hanzhixing]

Waited for a long time from last 0.200...

[c089]

Cross-referencing other threads these since I've also been wondering:

Possible Duplicate of #11352 Possible Duplicate of #12418

[robbyoconnor]

No, they're definitely dupes. On 8/8/19 2:45 AM, Christoph Neuroth wrote:

Cross-referencing other threads these since I've also been wondering:

Possible Duplicate of #11352 https://github.com/syl20bnr/spacemacs/issues/11352 Possible Duplicate of #12418 https://github.com/syl20bnr/spacemacs/issues/12418

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/syl20bnr/spacemacs/issues/11191?email_source=notifications&email_token=AAAFUMGPSFMROT2C3TX425LQDO6KFA5CNFSM4FQLNBY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD32UE5I#issuecomment-519389813, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAFUMGTWD6NUZ62643YRSTQDO6KFANCNFSM4FQLNBYQ.

[macintacos]

As a new user, it's disappointing that I had to spend almost an hour to figure that a layer that's been merged with develop since 2017 (!), treemacs (#9680), hasn't been merged with the default master branch and thus isn't included in a clean installation. I'll be trying my luck with the develop branch, but what's up with this release cadence?

Also, side note; I'm perfectly fine with unreleased features being documented, but it makes it a bit confusing to a casual user like myself that thinks that the documentation is detailing what's on the "latest stable" branch, i.e. the one that is installed from master. The layers documentation gave no indication that I wouldn't be able to enable treemacs until I was on the develop branch, which is why I'm a bit frustrated.

[l2dy]

Also, side note; I'm perfectly fine with unreleased features being documented, but it makes it a bit confusing to a casual user like myself that thinks that the documentation is detailing what's on the "latest stable" branch, i.e. the one that is installed from master. The layers documentation gave no indication that I wouldn't be able to enable treemacs until I was on the develop branch, which is why I'm a bit frustrated.

The layers documentation is under www.spacemacs.org, not develop.spacemacs.org. The domain is the indication.

[robbyoconnor]

develop almost never is unstable. If you want the latest, use that. If it ever does break, it's not broken for long and roll-back is easy.

On 11/27/19 12:00 AM, Zero King wrote:

Also, side note; I'm perfectly fine with unreleased features being
documented, but it makes it a bit confusing to a casual user like
myself that thinks that the documentation is detailing what's on
the "latest stable" branch, i.e. the one that is installed from
master. The layers documentation
<https://develop.spacemacs.org/layers/+filetree/treemacs/README.html>
gave no indication that I wouldn't be able to enable |treemacs|
until I was on the |develop| branch, which is why I'm a bit
frustrated.

The layers documentation https://www.spacemacs.org/layers/LAYERS.html is under www.spacemacs.org http://www.spacemacs.org, not /develop/.spacemacs.org. The domain is the indication.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/syl20bnr/spacemacs/issues/11191?email_source=notifications&email_token=AAAFUMEGPG5P7JVH5YDZZI3QVX5IHA5CNFSM4FQLNBY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFIJLVQ#issuecomment-558929366, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAFUMDZUILEYNK6JQZT7V3QVX5IHANCNFSM4FQLNBYQ.

[macintacos]

Touché @l2dy! Hadn't noticed the domain :)

Understand the workaround, and I'll be doing that going forward; just doesn't "feel" great.

[practicalli-johnny]

For future reference and anyone looking to upgrade from Spacemacs master to develop can use this comprehensive guide https://practicalli.github.io/spacemacs/install-spacemacs/switch-to-develop.html

[KitsuneSan89]

It's now been over 3 years since the last release. Is there any expectation that another release will happen, or should everyone just be on develop?

[real-or-random]

I think the answer is in this commit message:

https://github.com/syl20bnr/spacemacs/commit/964f4c5af3615b648a7707a39b82b7ef02dc4807#diff-44bd77bd979018c8610440ea263a5790522d32dee6f60d5187fbe7de9440f8d0

The master branch is using curated version of packages for increased stability.

However this approach proofed to be very work intensive and we have therefore stopped supplying those versions for now. As these packages are not longer updated you should consider migrating to the maintained "develop" branch.

I still think there should be some roadmap / tracking issue for further changes:

• Are there some (even rough) plans to revive the master idea or not? (Not wishing for any particular answer, I'm just asking).
• https://develop.spacemacs.org/ should be moved to https://www.spacemacs.org/
• Consider renaming the master branch and/or the develop branch
• The README should have a migration guide, or point to one. @practicalli-john wrote an excellent guide here: https://practical.li/spacemacs/install-spacemacs/switch-to-develop.html
• Close remaining duplicates, e.g. https://github.com/syl20bnr/spacemacs/issues/12418
• ...

[costa]

I'm sorry for the harsh words (especially coming from an ex-rails dev), but this project is off the rails...

I've been using it for many years, enjoyed its stability (while bringing order into Emacs chaos), and recommended to anyone serious about text management. It has become a professional tool of choice for many, many devs. Nowadays, the versions are like effectively totally gone — I mean, if I'd seen this project with no versions back when I started, there'd been no chance in hell (wink!) I'd been starting using it at all — it can be relied upon almost as much as your own first ~/.emacs in the olden days.

Now, I have a very modest setup, with essentially all defaults, and after many, many happy times (with almost no config tinkering), in recent years, it's been degrading on me from update to update, and in the last few days, even a clean fresh install of everything on my macos (maybe not the latest macos, but the brew's latest emacs app and github's latest spacemacs version) is now deficient wrt basic functionality (such as treemacs panel coming up — or even being able to replace treemacs with neotree).

I will be sorry to see good devs and also myself walk away from this project just because it failed on its main successful idea: stability of package configuration. I have not contributed to this project (no lisp here), but it seems unfair to those who did — denying good code from living on, potentially with others' forks of stable versions.

Is there at least a chance that there comes a hero who shall patch the latest stable version — while working around resurrecting old packages as needed (possibly marking stuff unsafe) — and make it work for the most popular layers at least? Thanks.

[practicalli-johnny]

As a minor contributor to the Spacemacs project I am very grateful to everyone who has contributed and to the original maintainer who started the project.

I am a long time used of Spacemacs develop branch (2015) and have rarely had any serious issues. I can upgrade to packages and pull Spacemacs changes as required without having to manage a big upgrade.

The rolling release model has been adopted by huge numbers of people and has long been the recommended approach by the community at large (from 2015 onward)

I do not believe a stable release schedule it's needed or valued highly (or someone would have done it already).

Having tried other community configurations earlier this year, I found no as feature rich, reliable and as easy to use as Spacemacs. I will continue using Spacemacs for the foreseeable future.

It is very sad to see rants disparaging all the work that everyone has committed and I would hope that people making such comments wonder why they are not helping instead (especially if those people don't even take the time to contribute anything)

There are plenty of choice with Emacs, so people can either help shape and evolve the Spacemacs project or they can take make an alternative choice.

[robbyoconnor]

@practicalli-john -- Yeah, if I ever face issues, they're usually not issues for long.

[costa]

...just as another screencast of mine is ruined by buggy(!) Ruby(!!) syntax highlighting (!!!)...