Question about releases

[pure-fish]

Question about releases

For the version scheme I recommend semver which is why I am used to in Node and found most practical.

We haven't published any releases so far so I was wondering if it makes sense to do at this point.

You can create an annotated Git tag with a version number or label and pass that to fisher install when you install a package:

fisher install pure@rafa-wild-release

or

fisher install [email protected]

We use annotated Git tags to version Fisherman too, also keep a comprehensive change log and create releases for each patch, minor and major bump.

[edouard-lopez]

As the installer is quite stable, I'm going to create a 1.0.0 release.

[oranja]

I don't know about fisherman, but OMF currently has no version-locking feature.
Even if it had, I believe it would be specified by a revision, which in the world of git means that you can either specify a commit or a (version) tag. If I'm correct, this scheme gives you flexibility not to name your tags with traditional version numbers, but with major changes instead. For example, "fish-2.1-compat" could be the last tag that still supports fish 2.1. The next commit depends on some features that were only introduced in fish 2.2. Alternatively, a user might decide that he doesn't like some changes made in the last few commits and wants to stay with commit 5ab58a3f (just throwing numbers here out of my head). It won't require any work on your side.

I can think of two common uses for version numbers:

1. Marketing - You bump numbers to make your clients feel they are missing something great if they don't purchase the latest, most expensive version. Or, depending on your business model, you bump numbers to make your clients feel like you are awarding them huge improvements "on the house".
2. Compatibility - This is especially relevant to frameworks, libraries and tools. Major version = major change; minor version = minor change; etc. As a vendor you have a chance to deprecate parts of the interface, and as a client you know when the deprecated interfaces are going to be gone.
   IMHO, neither of these apply here. So if I were you, I'd leave version numbers for now. At least until any framework supports revision locking. If you are happy with the theme then you shouldn't expect anything more than a few bugfix/enhancement commits in the near future. Nothing that justifies versioning anyway.
   I'd take it as a reason to be proud. It also frees you to start thinking about the next big challenge ;)

[rafaelrinaldi]

@bucaran yeah, I would use semver for that too. Do you use anything to automate change logs or you just do it manually?

[edouard-lopez]

I'm in favor of semver, it is widespread and getting more aknowledge every day and it's quite straight-forward:

Given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes,
  

• MINOR version when you add functionality in a backwards-compatible manner, and
  

• PATCH version when you make backwards-compatible bug fixes.
  

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

I would argue that when the installer is working we can release the first stable release 1.0.0. What do you think

[rafaelrinaldi]

@edouard-lopez That's exactly what I was thinking 👍

Do you use anything to automate change logs or you just do it manually?

To create a new version and commit it to the repo I use this:

• https://github.com/fisherman/fisherman/blob/master/Makefile#L34

For the change log, I write it manually, every word of it. 😄

[edouard-lopez]

Syntax

what's the $^, I never saw that in Bash… oh it's make variable

$^
The names of all the prerequisites, with spaces between them. For prerequisites which are archive members, only the named member is used (see Archives). A target has only one prerequisite on each other file it depends on, no matter how many times each file is listed as a prerequisite. So if you list a prerequisite more than once for a target, the value of $^ contains just one copy of the name. This list does not contain any of the order-only prerequisites; for those see the ‘$|’ variable, below.

For us

It should refer to the $PURE_INSTALL_DIR.

Workflow

So if I understand correctly (I skim throught code) your workflow is:

1. work on the project, version files
2. bump the VERSION file ;
3. run make release
4. and finally git push

Question

@bucaran why use git -C <path> instead of cd <path> at the begin and cd - at the end?

@rafaelrinaldi git -C is only used there actually. Other instances in Fisherman use an approach similar to what you suggest. The reason I still keep it like that in the Makefile, is because it saves a few strokes and at the moment I am the only person responsible for creating releases in Fisherman.

[edouard-lopez]

@rafaelrinaldi would you mind reviewing the release draft?

[rafaelrinaldi]

@edouard-lopez Let's do this! Draft looks good. Thanks to everyone who collaborated on this thread.

[edouard-lopez]

It's published !

[rafaelrinaldi]

Thanks for the discussion on this thread, lots of great insights here. Closing it since we already published two releases already 👍