Melpa stable

[nlamirault]

could you please create a tag to use this package using melpa stable [1].
Thanks

[1] : http://stable.melpa.org/

[MicahChalmer]

There isn't an obvious point to consider a release of rust-mode to be a "stable version" here. PRs get merged, and if there are problems more PRs are merged to fix them. If we added a tag, when would we be expected to add another?

[Wilfred]

It makes it easier to track changes, and it's really helpful for packages that depend on rust-mode. Without MELPA stable there isn't really much versioning.

If we added a tag, when would we be expected to add another?

Monthly? After major bugfixes or feature additions?

The other nice advantage of versioning is that it allows communication of the severity of changes. If rust-mode went from 2.0 to 3.0 it suggests that more APIs may have changed.

[ketsuban]

The main wrinkle that I can see is the track system Rust uses—not everyone sticks to nightly. Perhaps the repository should have branches mirroring the Rust tracks with each one providing a different package to MELPA Stable, so that if I use Rust stable I can install rust-mode-stable in Emacs and know that it will always be the appropriate mode for the version of Rust I'm working against.

[Wilfred]

I think all Rust users would want the latest version of rust-mode. The most recent changes have corrected highlighting, improved performance -- all things that that apply to all rust versions. Similarly, as a C programmer I wouldn't expect to have to update c-mode if I start a project in c99 instead of c89.

When packages depend on rust-mode (only one so far), they might want to depend on a minimum version. E.g. rust-playpen-region was added a few months ago and if I explicitly need that function, I would want to specify a minimum version of rust-mode that includes that function.

[nikomatsakis]

I think all Rust users would want the latest version of rust-mode.

I agree. Also, Rust syntax is quite stable and certainly any changes will
be largely backwards compat, so I'd expect new versions of rust-mode to
work great on older rust code.

On Sat, Sep 12, 2015 at 10:38 AM, Wilfred Hughes [email protected]
wrote:

I think all Rust users would want the latest version of rust-mode. The
most recent changes have corrected highlighting, improved performance --
all things that that apply to all rust versions. Similarly, as a C
programmer I wouldn't expect to have to update c-mode if I start a project
in c99 instead of c89.

When packages depend on rust-mode (only one so far), they might want to
depend on a minimum version. E.g. rust-playpen-region was added a few
months ago and if I explicitly need that function, I would want to specify
a minimum version of rust-mode that includes that function.

—
Reply to this email directly or view it on GitHub
#87 (comment).

[robinheghan]

Any lingering thoughts on this? I'm more or less just waiting for rust-mode to hit melpa stable :P

[Wilfred]

Who has the power to create tags? @nikomatsakis ?

[nikomatsakis]

@Wilfred I can create tags, what tag do you want?

[Wilfred]

How about 1.0?

[nikomatsakis]

@Wilfred ah, sorry, my mistake. I thought you meant add a label to the issue. You mean create a tag for the repository or melpa? I can also do that, but I don't know what it takes to integrate the two. In fact, I know basically nothing about melpa -- I tend to just install emacs packages from source, like some kind of oafish dinosaur -- so can someone point me at some docs on what to do here? Does melpa understand git? Where does it gets its information from? :)

[robinheghan]

@nikomatsakis Everywhere I read it says that all you have to do is to add a tag to the git repository. Melpa stable checks the git repo of every melpa repository, and builds a package based on the tags.

[Wilfred]

Does melpa understand git? Where does it gets its information from? :)

Normal MELPA just builds packages from git. You get the latest commit from master. MELPA helps discovery, makes it easy for users to upgrade, and fetches dependencies of any packages you install. Adding a package to MELPA simply requires adding a file that says where your package lives (e.g. here's the file for rust-mode).

Anyway, MELPA stable builds packages according to tags on a git repo. MELPA stable uses the same list of git repositories as normal MELPA. As a result, creating a tag (any version) would be sufficient.

[MicahChalmer]

If we add a tag with the right name format (i.e. compatible with the emacs version-to-list function, with an optional "v" prefix) it will add rust-mode to MELPA stable as of the commit that the tag points to. That's easy enough to do once. But git tags can't move (shouldn't be moved, anyway), so periodically more tags need to be added for later versions--otherwise MELPA stable will never upgrade and be stuck as it was when the first tag was added.

@Wilfred made some suggestions on frequency. Here are a few more:

• Add a tag for every push to master - this would be to say that rust-mode is "released" with every commit. Not a bad assumption given that this isn't updated all that often
• Match the rust releases, even though rust-mode's progress isn't really related to them--each cycle, add a tag here if there were commits since the last release

But in any case, there isn't a way to "set it and forget it" on this--people with commit access here would have to continually add new tags to avoid MELPA stable getting further and further behind. I think there needs to be an understanding of how it will be kept up to date before we add anything--better to have it not available in MELPA stable at all than to have it available, but on some arbitrarily old version that never updates.

[lvillani]

Why not create a new tag whenever a new version of Rust is released? Assuming there were changes between tags and that you deem the release to be stable, that would be at most once every six weeks. As a MELPA Stable user I would be fine with that and can tolerate minor bugs between releases.

I prefer a slightly older package than being subjected to bleeding edge code that breaks each time I refresh the package list. (Note that this is not a criticism against rust-mode, it's the rationale behind my decision to switch to MELPA Stable, induced by some packages -- like magit -- that like to constantly change the user interface or introduce regressions).

[kraai]

Having tagged revisions would also help with the Debian package of rust-mode that I'm working on. I'm currently using the latest Git revision, but the best practice seems to be to use a release instead.

[tromey]

First, I'm in favor of melpa-stable releases. I don't really like to add melpa to my repository list, because it doesn't play well with other repositories, due to its date-based versioning system.

rust-mode doesn't change so quickly that release management is a big burden. It's essentially always ready to release.

A melpa-stable release would require not just a tag, but also a bump to the Version header in rust-mode.el. So maybe releases could be done like other patches -- just wait for an interested party to submit a PR, I suppose with a reminder to push a tag.

[MicahChalmer]

@tromey your proposal makes sense to me. It doesn't promise that people would proactively do it (with nothing to enforce that) but lets there be a stable version there, since clearly a bunch of people want it and would benefit from it. If we adopt that, I think the README should call out that anyone who's using MELPA stable and waiting for some merged feature should file a PR to get it updated.

@nikomatsakis, what do you say?

[MicahChalmer]

There's now a tag for 0.3.0 (see #178) which followed the pattern proposed here. I'll leave this open to track that the instructions for getting MELPA stable updated should be added to the README instead of just here.

[nlamirault]

Great

[nlamirault]

Release is present on Melpa stable : https://stable.melpa.org/#/rust-mode