no releases?

[jrmarino]

There are zero tags on this repository. Are there no longer releases? Each release should be tagged to provide a verifiable version for packagers.

[jrcarter]

The PragmARCs have never had releases. They are updated occasionally. Each update gets a unique commit ID; the most recent is af0ce65. If you "watch" the repository you should be notified when this happens. You can use the most recent commit ID to identify the state of the repository when you packaged it.

[jrmarino]

Well, can you start versioning this? I don't want to speak to all the reasons why a no version policy is problematic to both packagers and users. I am EXTREMELY familiar with how versioning system and git in particular work, but please believe me when I say that nobody considers a hash as a release or a version identifier. (Yes, I know it is unique, but that's not relevant here). The best a packager can do is use the date of the comment and treat that is a version. It would be nice if repository followed a best practices.

If you could tag good points with a date such as "20230912" even that would be great. That would help a lot.

[jrcarter]

The PragmARCs as a whole do not have versions; I have no idea what one should call the current "version" of the library. The best I can think of would be the date, as you mentioned, but that is even less informative than the commit ID.

An advantage of this is that a user need only download and compile the new/changed files, not the entire library. Thus I am not sure that packaging makes sense for such a library.

It might be best for you to fork the repository. You can then add a tag of your choice to represent what you package.

[jrmarino]

well, let me ask you this. Do you use libraries from other sources? Are not every one of those libraries versioned and/or released? Having a library with no releases and no versions is not normal and definitely not best practices.

I don't really care that much to be honest. I'd sooner just drop the package. I was just packaging PragmARC as a service to ada users (and to you), but I'm not going to bend over backwards to do it.

[jrcarter]

The PragmARCs have been around for decades without versions or releases, and you are the first person to have an issue with it, so I don't see that adding a tag to it would make it better. But if I were to add a tag to the repository for your convenience, what should it be called?

[jrmarino]

well, I "had an issue" with PragmARC not having releases like 10 years ago. Perhaps that still makes me the first (to say it outloud) but it's not a new thing. Plus, if it's "wrong" not to have been versioning this the whole time, that's now being used as justification to continue doing the wrong thing?

All I'm asking for is a consistent versioning scheme, ideally when the library is in a good state. The easiest is a date-based tag, but you could simply increment a number. e.g. 20230905, 20230905a, 20230906 e.g. 12, 13, 14 e.g. 1.12, 1.13, 1.14

I'm not suggesting tag every commit. Just a tag that would represent the library in a good state.

[jrcarter]

Maybe I should have said "only". My point is that, after decades of existence and many users, if only one person has an issue with this, it's unlikely to be "wrong".

Typically the library is in a "good state" after every commit. I could add a tag every time you want to update your package if a tag every commit is too frequent.

[jrmarino]

no, it is definitely wrong. That's not up for debate. Go to any linux, BSD, or even windows package repository and you will not find unversioned libraries. Even individual users for individual projects are left to wonder if they need to rebuild with the latest.

So normally a release contains a lot more than one change. For example, let's say there are 10 commit sets between release v99 and release v100. Perhaps the repos is in a good state after ever commit set, but it's not considered a new release. So I would say the first commit set after v99 is "patch 1". so if you add all 10 "patches" to v99, you end up with the equivalent of release v100.

and that's what I would do as a packager. let's say you released v99, but it had a critical flaw that was fixed in the next commit set. I would rebuild the package as v99p1 or something like that, using the commit tag of the commit following the release.

So you as the author decide what should be a new release. But me as a packager will likely only build the tagged commits because I'll assume anything after that is "pre-release" work, and therefore not really suitable to package. I wait for the author to me when the repo is in a release state by watching for the tags.

[jrcarter]

I have added a tag to the repository.

[jrmarino]

I appreciate that, but "tag1" wouldn't be suitable for a release, unless your planned pattern is "tag1, tag2, tag3, ... tagN". But if you are going to do that, then might has well go with the "v" convention, e.g. "v1,v2,v3,...,vN" The prefix "v" with the release is a very common convention with git tagged releases.

[jrmarino]

I used "tag1" to create version 1: https://github.com/Ravenports/ravensource/commit/8d4e69bc737bde467e6e7d24c0fd9f1a1c41f618

If you want to keep using the prefix "tag" it's fine. It's weird, but it's fine. When you want to signal a new release, just tag it with the suffix of "2" (since I assume you want to use incrementing integers as your version scheme)

[jrcarter]

I decided to use your suggestion of successive integers, and started with "1", but Github rejected that. Apparently it has to start with a letter. So I thought about what this is "1" of. It's not the first version, since that was around 1990. But it's definitely the first tag in the repository, so I tried "tag 1". That was also rejected, due to the space, so I removed that and ended up with tag1. Possibly if the rules for tag names had been presented up front I would have chosen something else. I might change for future tags.