New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Could Alacritty start tagging versions? #1240

Closed
anko opened this Issue Apr 10, 2018 · 13 comments

Comments

Projects
None yet
9 participants
@anko

anko commented Apr 10, 2018

Even if you don't feel "worthy" of a 1.0 for some reason, the reality is that people are using and packaging alacritty, and it would be reassuring if the commits packagers are checking in as the current version of alacritty into packaging systems aren't just their best guesses for okay cut points.

Even if the version is 0.x, would it be possible to start tagging versions occasionally?

My horse in this race is getting the Void Linux alacritty package updated, but I'm sure other distros' packagers would love to see versions tagged too.

@jwilm

This comment has been minimized.

Owner

jwilm commented Apr 10, 2018

That sounds reasonable. I was going to do this when we start shipping binaries, but perhaps it's best not to block on that given that people are, as you say, packaging Alacritty in official repositories.

From your perspective as a packager, would it be helpful to add a tag to the current master as it is today? Naturally, future releases would be tagged as well.

@chrisduerr

This comment has been minimized.

Collaborator

chrisduerr commented Apr 10, 2018

What exactly speaks against just shipping binaries too? Once version tagging is done it would be easy to automatically build for macos/linux with travis.

@anko

This comment has been minimized.

anko commented Apr 10, 2018

@jwilm If the current master head commit feels to you like something that could be a "version" (a relatively stable fixed point between feature branch merges, something people could be using as software without being a developer), then yes—I'd love for that to be tagged. Or whatever is the latest such commit.

However, if you feel the project is still in so much flux that no commit stands out as more stable or version-cuttable than the others, then no—it wouldn't add any new information.

@chrisduerr

This comment has been minimized.

Collaborator

chrisduerr commented Apr 10, 2018

I don't think adding versions to point out any kind of "stability" makes sense before 1.0. I would expect every commit that lands on master to be expected to work properly without introducing a bunch of regressions. At the same time I wouldn't expect any kind of "stability" guarantee from any of them.

Tagging versions is more about showing a difference I'd say. If there's just a bunch of commits which rework the config file/README/other stuff not directly impacting features, I would not tag versions because it doesn't add any direct improvement for the user.
However when new features are introduced that people are looking forward to (for example the scrollback branch which users are using even now before it's introduction into master), it should be indicated that there was a significant change which makes it "worth" to update the application.

So in summary, I'd stay away from promising any kind of "stability" and focus more on making clear when significant changes have been introduced.

I don't think it's hugely revelant if current master gets tagged or we wait until other features are added and start with future commits, as long as a consistent versioning scheme is started for maintainers.

@anko

This comment has been minimized.

anko commented Apr 10, 2018

@chrisduerr I agree. That's what I meant by "relatively stable"; stable compared to other work-in-progress commits. It was probably a bad word choice. 😅 You explained it much better.

@vbrandl

This comment has been minimized.

vbrandl commented Apr 23, 2018

Maybe a bit OT but also not worth a separate issue:
If you are looking to ship binaries, I'd like to point out https://github.com/japaric/trust to automatically generate binaries for a variety of operating systems, architectures and libc implementations. I've used it myself (on a toy project) and it worked fine.

@jwilm

This comment has been minimized.

Owner

jwilm commented Apr 23, 2018

@vbrandl that will be helpful for #80 / #1090 / #927 (just realized we have a bunch of dupes and tagged them all).

@davidak

This comment has been minimized.

davidak commented Apr 29, 2018

FYI: alacritty is currently packaged in 5 independent repositorys.

https://repology.org/metapackage/alacritty/versions

Rather stable 0.x releases would be great.

@FliiFe

This comment has been minimized.

FliiFe commented May 6, 2018

Versioning with tags would be of great help. I packaged alacritty on gentoo (the ebuild proposed in the readme is not working anymore), and it is kind of a pain to use live ebuilds to package it.
Tags would allow for easy versioning of packages across all distributions.

@clawoflight

This comment has been minimized.

clawoflight commented May 8, 2018

+1 from here. I'm not maintaining the Arch package, but I know from my own experience with other projects that it's really helpful to have tags.
Even if you only, say, bump 0.1.0 by ..1 when a group of features land.
That will also make versions comparable between distros and help with error reporting :)

@kpcyrd

This comment has been minimized.

kpcyrd commented May 21, 2018

FYI: alacritty is currently packaged in 5 independent repositorys.
https://repology.org/metapackage/alacritty/versions

Note that most of those seem to package random commits instead of actual releases. There's currently no non -git package for alacritty in the archlinux user repository because that would require tags. I think if and how binaries should be shipped is a separate issue, as this is potentially more complex then just "every update that is pushed to crates.io should be tagged in git" :)

@chrisduerr

This comment has been minimized.

Collaborator

chrisduerr commented May 21, 2018

crates.io will probably take longer than both tagging versions and providing github builds.

Based on the last time I looked into it, as soon as versions are tagged, it should be no problem to provide binaries through travis + github.

@mynameisfiber

This comment has been minimized.

Contributor

mynameisfiber commented May 25, 2018

With #1329, we can get debian/osx builds on tags (and nightlies for that matter).

chrisduerr added a commit to chrisduerr/alacritty that referenced this issue Aug 5, 2018

Bump version number to 0.2.0
Since the Scrollback branch introduces some major changes, this bumps
the version number from 0.1.0 to 0.2.0.

The versions of Alacritty have not been updated regularly to this point,
so the scrollback branch is a good point in time to start updating
Alacritty's version on a regular basis.

Further changes to the readme, like dropping the 'alpha' status and
updating it to 'beta' could also be introduced with this branch. This
way there will be a clean cut which updates everything as soon as
scrollback is merged.

Building versions is another thing which would be a good thing to start
reasonably quickly. However starting this on the main branch after
scrollback has been merged seems like a more reliable way to move
forward.

This fixes jwilm#1240.

chrisduerr added a commit to chrisduerr/alacritty that referenced this issue Aug 5, 2018

Bump version number to 0.2.0
Since the Scrollback branch introduces some major changes, this bumps
the version number from 0.1.0 to 0.2.0.

The versions of Alacritty have not been updated regularly to this point,
so the scrollback branch is a good point in time to start updating
Alacritty's version on a regular basis.

Further changes to the readme, like dropping the 'alpha' status and
updating it to 'beta' could also be introduced with this branch. This
way there will be a clean cut which updates everything as soon as
scrollback is merged.

Building versions is another thing which would be a good thing to start
reasonably quickly. However starting this on the main branch after
scrollback has been merged seems like a more reliable way to move
forward.

This fixes jwilm#1240.

This was referenced Aug 21, 2018

chrisduerr added a commit to chrisduerr/alacritty that referenced this issue Sep 2, 2018

Bump version number to 0.2.0
Since the Scrollback branch introduces some major changes, this bumps
the version number from 0.1.0 to 0.2.0.

The versions of Alacritty have not been updated regularly to this point,
so the scrollback branch is a good point in time to start updating
Alacritty's version on a regular basis.

Further changes to the readme, like dropping the 'alpha' status and
updating it to 'beta' could also be introduced with this branch. This
way there will be a clean cut which updates everything as soon as
scrollback is merged.

Building versions is another thing which would be a good thing to start
reasonably quickly. However starting this on the main branch after
scrollback has been merged seems like a more reliable way to move
forward.

This fixes jwilm#1240.

chrisduerr added a commit to chrisduerr/alacritty that referenced this issue Sep 5, 2018

Bump version number to 0.2.0
Since the Scrollback branch introduces some major changes, this bumps
the version number from 0.1.0 to 0.2.0.

The versions of Alacritty have not been updated regularly to this point,
so the scrollback branch is a good point in time to start updating
Alacritty's version on a regular basis.

Further changes to the readme, like dropping the 'alpha' status and
updating it to 'beta' could also be introduced with this branch. This
way there will be a clean cut which updates everything as soon as
scrollback is merged.

Building versions is another thing which would be a good thing to start
reasonably quickly. However starting this on the main branch after
scrollback has been merged seems like a more reliable way to move
forward.

This fixes jwilm#1240.

@jwilm jwilm closed this in ca1b75b Sep 17, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment