cypht
cypht copied to clipboard
cypht-org
Document / facilitate the migration from https://hub.docker.com/r/sailfrog/cypht-docker to https://hub.docker.com/u/cypht
https://github.com/cypht-org/cypht-docker/ was the official Docker image builder of Cypht. It is being replaced:
- Docker-related code will be part of the main Cypht repository so https://github.com/cypht-org/cypht-docker/ will be deprecated.
- https://hub.docker.com/u/cypht will replace https://hub.docker.com/r/sailfrog/cypht-docker as per https://github.com/cypht-org/cypht/issues/1016
- Here is background info: https://github.com/cypht-org/cypht-docker/issues/31
This issue is to track what should be done to facilitate this transition once https://hub.docker.com/u/cypht is working well enough.
As of 2024-05-25, https://hub.docker.com/r/sailfrog/cypht-docker/ is serving up 5 month old code from Cypht master, which is missing a lot of fixes and enhancements compared to Cypht 2.0.x or today's master.
Until https://hub.docker.com/u/cypht is operational, https://hub.docker.com/r/jonocodes/cypht can be used to test https://github.com/cypht-org/cypht/pull/1001
We should probably take down the sailfrog image eventually but I dont think it has to happen for a while.
Once the new image is up in https://hub.docker.com/u/cypht we should update the readme on https://hub.docker.com/r/sailfrog/cypht-docker to point people to the new cypht/cypht image.
Also since I have creds now I can publish something right away to cypht/cypht. I'm just not sure what to tag to use. Maybe it will just be a timestamp or something cryptic so its not yet used. Or perhaps I'll just use 'latest' for now.
Also also we should probably merge this first: https://github.com/cypht-org/cypht/pull/1001 Preferably someone will 'accept' it before I merge.
Also since I have creds now I can publish something right away to cypht/cypht.
Yes, please just go for cypht/cypht
Preferably someone will 'accept' it before I merge.
Done and merged.
We used to only have master, fewer developers, and all MRs reviewed by Jason Munro (project founder), so master was kept very stable.
But now
- Jason is on a break.
- the community is bigger, more projects are underway.
- mistakes will be made: several junior devs who will make mistakes + senior devs who will work on more complex things, which will also lead to issues.
So I decided we would have stable branches: https://github.com/cypht-org/cypht/wiki/Lifecycle
Thus, it's OK to have some short term mess in master while we figure out things like this.
I'm just not sure what to tag to use. Maybe it will just be a timestamp or something cryptic so its not yet used. Or perhaps I'll just use 'latest' for now.
I don't know enough on how this works to provide guidance.
We should probably take down the sailfrog image eventually but I dont think it has to happen for a while.
Agreed. Just put a readme pointing to new location.
I'm just not sure what to tag to use. Maybe it will just be a timestamp or something cryptic so its not yet used. Or perhaps I'll just use 'latest' for now.
So 'latest' would be Cypht master? Why not call it master?
Oh wow!
- https://vsupalov.com/docker-latest-tag/
- https://medium.com/@mccode/the-misunderstood-docker-tag-latest-af3babfd6375
- https://www.howtogeek.com/devops/understanding-dockers-latest-tag/
Oh wow!
* [vsupalov.com/docker-latest-tag](https://vsupalov.com/docker-latest-tag/)
Ha yes. I was about to post the same article. Long story short is 'latest' is not well defined and not well understood. Makes more sense for development then distribution - though some projects have started taking it upon them selves to keep it meaningful in their project specifically.
I would say the same problem is for 'master'. When in 'master' was it made? Today? Last month?
There was talk of a 'nightly' tag, which I think may be more meaningful - that is if it is really nightly.
I personally try to avoid these altogether when distributing images. And stick to version numbers. That way you know what you are getting.
All that being said I have posted to 'latest' while we figure that out: https://hub.docker.com/r/cypht/cypht
We can delete that tag if we want, but it will be more clear when a release happens. By the way, this maybe would be a good time to do a release? Then we can get a real version number in there.
By the way, this maybe would be a good time to do a release? Then we can get a real version number in there.
Sure! @josaphatim can release 2.0.2 Does he need to do anything different than 2.0.1?
By the way, this maybe would be a good time to do a release? Then we can get a real version number in there.
Sure! @josaphatim can release 2.0.2 Does he need to do anything different than 2.0.1?
I hate to nit-pick. But this would be a feature release not a bug fix. So to stick inline with symantic versioning it would be 2.1.0. But I guess that would mess with the support schedule?
But I guess that would mess with the support schedule?
No, it wouldn't. 2.1.x will just replace 2.0.x as the supported stable branch.
I hate to nit-pick. But this would be a feature release not a bug fix. So to stick inline with semantic versioning it would be 2.1.0.
This is a good topic. We set general guidelines, but it's only when it hits reality that we can refine our processes. Thank you. I didn't see this as a new feature because nothing changes for the user. But for a sysadmin, it is significant and they should review the changelog. I am fine to tag it 2.1.0 (And say 2.0.x is EoL)
On a related note, master will soon diverge in a material way from 2.x, by requiring PHP 8.1+: https://github.com/cypht-org/cypht/pull/1044. So the Docker files will need to diverge as well.
@jonocodes should https://github.com/cypht-org/cypht/pull/1044 be held back?
@josaphatim please release Cypht 2.1.0
We should probably take down the sailfrog image eventually but I dont think it has to happen for a while.
Once the new image is up in https://hub.docker.com/u/cypht we should update the readme on https://hub.docker.com/r/sailfrog/cypht-docker to point people to the new cypht/cypht image.
Yes, we should take it down but I think not now. For the moment we can just update the readme adding a deprecated message and a link to https://hub.docker.com/u/cypht so people will know where the new image lives. And after a while we can take down the sailfrog image.
All that being said I have posted to 'latest' while we figure that out: https://hub.docker.com/r/cypht/cypht
We can delete that tag if we want, but it will be more clear when a release happens. By the way, this maybe would be a good time to do a release? Then we can get a real version number in there.
Thanks for the new image posted, we can now update sailfrog image readme to point to https://hub.docker.com/u/cypht.
@jonocodes should https://github.com/cypht-org/cypht/pull/1044 be held back?
I think it can get merged. Then the first real docker release would be php 8. The docker work will not be hard. Side note: I'm away from computer for a few days.
But you do need to consider the cypht version. Maybe 2.1.0 is fine for a php upgrade since it does not seem to be a breaking change at this point.
I hate to nit-pick. But this would be a feature release not a bug fix. So to stick inline with semantic versioning it would be 2.1.0.
This is a good topic. We set general guidelines, but it's only when it hits reality that we can refine our processes. Thank you. I didn't see this as a new feature because nothing changes for the user. But for an sysadmin, it is significant and they should review the changelog. I am fine to tag it 2.1.0 (And say 2.0.x is EoL)
It can be a little unintuitive but when I work on projects I favor revving the middle number the most. Thats the default. On another project I'm working on It's not uncommon that the minor version will update several times a day (ie 2.3.4 to 2.4.0 to 2.5.0).
I reserve the last digit to mean this release only fixes a bug and we don't think it would lead to a regression. It's more of an emergency valve that should not happen often.
Maybe 2.1.0 is fine for a php upgrade since it does not seem to be a breaking change at this point.
Ok, let's do that. And it will make it easier to backport things from Cypht master to 2.x (which I expect we will do a lot of). I updated: https://github.com/cypht-org/cypht/wiki/Lifecycle
Users who are stuck on PHP 7.4 (or even all the way back to PHP 5.6) can use Cypht 1.4.x which is LTS.
Here is task: https://github.com/cypht-org/cypht/issues/1050
I reserve the last digit to mean this release only fixes a bug and we don't think it would lead to a regression. It's more of an emergency valve that should not happen often.
That was pretty much my original idea for the general lifecycle except I didn't even plan for the last digit. So I had in mind 2.0, 2.1, 2.2, etc. but 2.0.0, 2.1.0, 2.2.0, etc. is better with the emergency valve as you call it :-)
So we'll very likely get to 2.10.0 before we release 3.0, which is fine!
Also to do: update instructions on https://www.cypht.org/install-2x.html
We should probably take down the sailfrog image eventually but I dont think it has to happen for a while.
Once the new image is up in https://hub.docker.com/u/cypht we should update the readme on https://hub.docker.com/r/sailfrog/cypht-docker to point people to the new cypht/cypht image.
@marclaporte I updated https://hub.docker.com/r/sailfrog/cypht-docker overview. I think we/you should also announce the migration of cypht docker image to the new account on https://app.gitter.im/#/room/#cypht-org_community:gitter.im.
OK. Perhaps wait to announce until we have a proper tag in the new repo.
ok, I pointed people here so they get latest status
Also to do: update instructions on https://www.cypht.org/install-2x.html
Also to do: update instructions on https://www.cypht.org/install-2x.html
https://github.com/cypht-org/cypht-website/pull/60
Ok, I have created a tag cypht/cypht:2.0.1 where I backfilled the docker work on top of the 2.0.1 git tag. Then I removed 'latest' from dockerhub for now. For reference you can see the work here: https://github.com/jonocodes/cypht/tree/2.0.1-docker
Lets call this the first official tag and go ahead and update docs/announce. Next I need to figure out how to build for ARM.
This updates old references: https://github.com/cypht-org/cypht/pull/1053
Not sure what the PR review policy before merging is.