Release 1.0

[grahamc]

No description provided.

[curiousleo]

Related: #269

[curiousleo]

Does "1.0" mean we're ditching the "number of commits" version scheme that's currently built into release.nix and lorri upgrade?
Also see #269 (comment)

[grahamc]

I think we should keep those numbers, and also add a real version number. Is that silly?

[curiousleo]

I think we should keep those numbers, and also add a real version number. Is that silly?

I think that has the potential to confuse users. My radical proposal for this would be:

• remove lorri upgrade and changelog parsing; I don't think we need it
• take release.nix and turn it into a CHANGELOG.md with entries for the so-far released versions unstable-2019-10-30 and unstable-2020-01-09
• from this point on, use a semantic-ish x.y.z versioning scheme and update CHANGELOG.md like a conventional changelog, e.g. this one.

[Profpatsch]

* remove `lorri upgrade` and changelog parsing; I don't think we need it

I use it regularly to update lorri to current master, it’s great (also for trying out in-progress branches once #168 is merged)

[Profpatsch]

Apart from that we should make an effort to check that every part of the command line is as stable as possible, and what parts of the command line are intended for machine-readable output; e.g. we wouldn’t want people to start parsing the output of lorri info or even lorri watch.

[curiousleo]

@Profpatsch wrote:

I use it regularly to update lorri to current master, it’s great (also for trying out in-progress branches once #168 is merged)

I think we've discussed this before - you use lorri self-upgrade, I don't (git checkout <branch> && nix-build . works well enough for me), therefore I see it mainly as something that increases the cost of maintaining lorri whereas you see it as something that adds value. I don't see a way towards a consensus on this.

[curiousleo]

@Profpatsch wrote:

Apart from that we should make an effort to check that every part of the command line is as stable as possible, and what parts of the command line are intended for machine-readable output; e.g. we wouldn’t want people to start parsing the output of lorri info or even lorri watch.

Yes. It's a bit unfortunate that this discussion is happening on two issues at once -- also see #269 (comment):

@curiousleo wrote:

We could adopt semantic versioning here, in which case we would need to define precisely what "incompatible change" means for lorri in terms of subcommands, arguments, outputs and behaviour.

And yes, it would be useful to make the distinction between subcommands meant for machines and those made for humans. The former would have to have stricter compatibility guarantees.

[curiousleo]

@grahamc any reason this ticket is called "Release 1.0" and not "Release 1.0.0"? The latter would lend itself better to a semantic-ish versioning scheme.

Edit: I've started working on #311 and my thought after trying to specify when a lorri release should be a patch release vs. when it should be a minor release is that this distinction feels quite artificial for a command line tool. So perhaps we don't need a patch component in the version.

Edit: Here's my MAJOR.MINOR version scheme proposal: #312.

@Profpatsch what's your take on the versioning scheme - say we keep lorri self-upgrade, which enforces the "revCount" version, should we have a semantic-ish versioning scheme (starting from 1.0[.0]) alongside it? (Ref: #306 (comment))

[Profpatsch]

you use lorri self-upgrade, I don't (git checkout <branch> && nix-build . works well enough for me), therefore I see it mainly as something that increases the cost of maintaining lorri whereas you see it as something that adds value.

#168 was intended as a way to more easily get people to test out changes, so they don’t have to check out the repository and switch to the right branch and build and install. That eases maintenance.
I don’t know how exactly it adds maintenance overhead, it’s fairly static code that shouldn’t change very often.

[Profpatsch]

@Profpatsch what's your take on the versioning scheme - say we keep lorri self-upgrade, which enforces the "revCount" version

I don’t think lorri self-upgrade strictly needs to enforce revCount. We can just inject the branch name and the git revision, plus maybe the release version it is based on.

[Profpatsch]

So, what I’m saying is let’s remove the changelog stuff from self-upgrade if it’s too much hassle to maintain and just make it into a very simple way to install a specific version, for debugging purposes.

[curiousleo]

To do (also see https://github.com/target/lorri/blob/master/MAINTAINERS.md#publishing-a-release-on-nixpkgs):

• Bump version in Cargo.toml
  PR: Prepare 1.0 release #323
• Tag release at 88c680c

  $ git tag 1.0 88c680c9abf0f04f2e294436d20073ccf26f0781 && \
    git push origin 1.0
  

• Release to nixos-unstable
  PR: lorri: unstable-2020-01-09 -> 1.0 NixOS/nixpkgs#79230
• Release to nixos-19.09
  PR: lorri: unstable-2020-01-09 -> 1.0 (backport to release-19.09) NixOS/nixpkgs#79261

[Profpatsch]

Everything’s done, closing.