Skip to content
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

Have a GIT specific tag for docker and use the LATEST tag for the latest version. #421

Closed
Gontier-Julien opened this issue Apr 23, 2023 · 6 comments

Comments

@Gontier-Julien
Copy link
Contributor

The latest tag in docker is currently from the commits, it should be better to have a git specific tag and have the latest tag to pull the latest version of inadyn.

@Gontier-Julien Gontier-Julien changed the title Have a GIT specifi tag for docker and use the LATEST tag for the latest version. Have a GIT specific tag for docker and use the LATEST tag for the latest version. Apr 23, 2023
@Gontier-Julien
Copy link
Contributor Author

I might take a look "soonish" when i got time, but one thing that could simply this and make it easier would be to make all the development on the dev branch instead, and when a new release come up, just sync all the change back to the main branch.

This would make it much easier to automate it with GitHub actions and have the latest tag be the latest stable version from themain branch and the git on being the development one.

(i say git as a tag but it could be named dev or something like that as you want haha)

@troglobit
Copy link
Owner

Please don't build anything on a change of development practices.

As things are now, and have been for the last 15 years, I'm the only developer here, and as things are right now I'm more inclined to a) drop docker support entirely, or b) just abandon/archive this project entirely.

Because there's just not enough people stepping up to really help out and serve as maintainers. There are, however, lots of people with opinions on how I should do the job, for free, I might add.

Here is free advice: instead of imposing restrictions, focus on automation. If you're unsure how releases and development are done, asks questions.

@Gontier-Julien
Copy link
Contributor Author

I'm not imposing restrictions or anything and not telling you how you should develop thing or anything don't worry!
I was just proposing an idea to you, i don't want you too feel bad about it or anything

And i would like to help this project, but it been a long time since i've developed thing in C tbh, i could learn it if it could help you, but as of right now i don't have the spare time to do it..

And as for docker i could take charge of it, if it can help you out! I just currently don't know how to automate it with github actions to have it as a stable release, but i could do it manually which is no problem for me.

Sorry tho have you feel this way, it wasn't my intention at all, i'm really thankful that you've been maintaining this project this far as it is really useful <3

@troglobit
Copy link
Owner

OK. There have been many requests for changing development practices and build systems over the years, it's tiresome and I guess I'm a bit too sensitive when ppl bring things like that up. All I'm saying is that, for this particular issue I don't see any reason to change development practices (using a dev branch instead of just using master).

Now, I vaguely remember this particular issue coming up in something else (a pull request maybe?) and I suggested adding a separate issue for it. Remind me, what is it you wanted to achieve with this, was it to change :latest to be the latest released version and use :GIT_HASH, or something, for what today is :latest? I've tried to read up a bit on best practices, since I don't personally rely on Docker too much, and I found this: https://stevelasker.blog/2018/03/01/docker-tagging-best-practices-for-tagging-and-versioning-docker-images/, which suggests using build-ids. GitHub actions have ${{github.run_number}} that we can use.

And just to follow-up on the maintainer thing. There are plenty of tasks to do beside C code. Answering questions, testing providers, improving documentation, etc. Here are a few:

@troglobit
Copy link
Owner

I've whipped up a proposal for fix in #441, would be very appreciated if you could review to see if my speculative change has a chance of actually working.

@Gontier-Julien
Copy link
Contributor Author

OK. There have been many requests for changing development practices and build systems over the years, it's tiresome and I guess I'm a bit too sensitive when ppl bring things like that up. All I'm saying is that, for this particular issue I don't see any reason to change development practices (using a dev branch instead of just using master).

Now, I vaguely remember this particular issue coming up in something else (a pull request maybe?) and I suggested adding a separate issue for it. Remind me, what is it you wanted to achieve with this, was it to change :latest to be the latest released version and use :GIT_HASH, or something, for what today is :latest? I've tried to read up a bit on best practices, since I don't personally rely on Docker too much, and I found this: https://stevelasker.blog/2018/03/01/docker-tagging-best-practices-for-tagging-and-versioning-docker-images/, which suggests using build-ids. GitHub actions have ${{github.run_number}} that we can use.

And just to follow-up on the maintainer thing. There are plenty of tasks to do beside C code. Answering questions, testing providers, improving documentation, etc. Here are a few:

* [`input in flex scanner failed` #440](https://github.com/troglobit/inadyn/discussions/440)

* [Docker appears to not have SSL (latest and v.2.11.0 tag) #429](https://github.com/troglobit/inadyn/issues/429)

* [No arm platform packages on github #396](https://github.com/troglobit/inadyn/issues/396)

Very understandable don't worry ^^
And since i have some time today i'll take a look!

troglobit added a commit that referenced this issue Aug 9, 2023
Fix #421: use Docker :latest tag only for latest In-a-Dyn release
@troglobit troglobit added this to the v2.12.0 milestone Aug 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants