New version

[Cellesti]

Hi, i am the maintainer of the Ktistec package in Alpine Linux. It was recently brought to my attention that the Alpine package has misinterpreted the versioning scheme you use.

As the - character is not allowed in versions for Alpine packages, we turned it into a ., so 2.0.0-11 became 2.0.0.11.

With the release of 2.0.0, we have realized our mistake, that you intended 2.0.0-11 to be a pre-2.0.0 release.

However that is a bit too late, Alpine's package manager considers 2.0.0.11 a post-2.0.0 version, so if we add 2.0.0 into the repository, the package manager will not automatically upgrade to it.

We will learn from this, and in the future, if you tag 3.0.0-1 we will translate it into a version the package manager recognizes as a pre-3.0.0 version.

For now, i am writing to you to ask about the possibility of having a 2.0.1 release, so over at Alpine, we will be able to provide a straightforward upgrade path for our users.

Considering that you've just tagged 2.0.0, i understand you may have reservations about tagging another version so soon afterwards, but i hope you will give this request some consideration.

Thanks.

[toddsundsted]

For now, i am writing to you to ask about the possibility of having a 2.0.1 release, so over at Alpine, we will be able to provide a straightforward upgrade path for our users.

of course. i just tagged v2.1.0 which includes upgrades for application dependencies. i hope this helps resolve this for you!

[toddsundsted]

and then i screwed up my own tagging scheme and tagged commits on the main branch instead of the dist branch. can you hold off on making a new release until i fix that.

[toddsundsted]

ok, git tags fixed.

[Cellesti]

Thanks for accommodating my request :)

On another note, i think shard.lock needs updating, but i can workaround that downstream with a patch, so will leave it up you whether you think this warrants having yet another new tag.

[toddsundsted]

what triggers a new release? is the tagging a commit in git or is it updating the version in shards.yml? are you packaging main or dist?

[Cellesti]

what triggers a new release?

People :)

I haven't heard of any Alpine Linux maintainer using a fully automated process to update packages they maintain, so every update has a human behind it.

are you packaging main or dist?

I added Ktistec to Alpine repositories on 27th December last year, and have always packaged dist.

The first 3 version updates were packaged straight out of commits from dist (usually when i noticed an "Update shard.lock" commit).

Later on, another contributor switch to packaging git tags, and handled the 2.0.0-10 and 2.0.0-11 updates. Those tags also correspond to commits from dist.

is the tagging a commit in git or is it updating the version in shards.yml?

I think i would go with the former, we derive the url of the source archive based on the package version.

We can then add patches to be applied to that source, so for example, i can run shards update and make a patch out of the changes needed.

(When i was packaging straight out of git commits, i would manually copy the commit hash i was packaging.

I am still able to do this, but as the switch to packaging git tags has been made, i would prefer not to.)

[Cellesti]

I have updated shard.lock and made Ktistec 2.1.0 available in Alpine repos.

So, i consider this issue solved as nothing else needs to be done. Thanks for your time.

[toddsundsted]

@Cellesti thanks!

i will be making a new release in a short time. i will endeavor to get all of the steps correct on my end so that no patches are necessary.

[toddsundsted]

@Cellesti i have just released 2.2.0

let me know if you run into problems packaging this