mirror of
https://github.com/cypht-org/cypht.git
synced 2026-04-26 21:46:02 +03:00
[GH-ISSUE #1047] Document / facilitate the migration from https://hub.docker.com/r/sailfrog/cypht-docker to https://hub.docker.com/u/cypht #560
Labels
No labels
2fa
I18N
PGP
Security
Security
account
advanced_search
advanced_search
announcement
api_login
authentication
awaiting feedback
blocker
bug
bug
bug
calendar
config
contacts
core
core
devops
docker
docs
duplicate
dynamic_login
enhancement
epic
feature
feeds
framework
github
github
gmail_contacts
good first issue
help wanted
history
history
imap
imap_folders
inline_message
installation
keyboard_shortcuts
keyboard_shortcuts
ldap_contacts
mobile
need-ssh-access
new module set
nux
pop3
profiles
pull-request
question
refactor
release
research
saved_searches
smtp
strategic
tags
tests
themes
website
wordpress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/cypht#560
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @marclaporte on GitHub (May 24, 2024).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/1047
Originally assigned to: @jonocodes, @rodriguezny on GitHub.
https://github.com/cypht-org/cypht-docker/ was the official Docker image builder of Cypht. It is being replaced:
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.
@marclaporte commented on GitHub (May 25, 2024):
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
@jonocodes commented on GitHub (May 25, 2024):
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.
@jonocodes commented on GitHub (May 25, 2024):
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.
@jonocodes commented on GitHub (May 25, 2024):
Also also we should probably merge this first: https://github.com/cypht-org/cypht/pull/1001
Preferably someone will 'accept' it before I merge.
@marclaporte commented on GitHub (May 25, 2024):
Yes, please just go for cypht/cypht
@marclaporte commented on GitHub (May 25, 2024):
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
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.
@marclaporte commented on GitHub (May 25, 2024):
I don't know enough on how this works to provide guidance.
Agreed. Just put a readme pointing to new location.
@marclaporte commented on GitHub (May 25, 2024):
So 'latest' would be Cypht master? Why not call it master?
@marclaporte commented on GitHub (May 25, 2024):
Oh wow!
@jonocodes commented on GitHub (May 25, 2024):
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.
@jonocodes commented on GitHub (May 25, 2024):
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.
@marclaporte commented on GitHub (May 25, 2024):
Sure! @josaphatim can release 2.0.2 Does he need to do anything different than 2.0.1?
@marclaporte commented on GitHub (May 25, 2024):
+1
@jonocodes commented on GitHub (May 25, 2024):
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?
@marclaporte commented on GitHub (May 25, 2024):
No, it wouldn't. 2.1.x will just replace 2.0.x as the supported stable branch.
@marclaporte commented on GitHub (May 25, 2024):
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.
@marclaporte commented on GitHub (May 25, 2024):
@jonocodes should https://github.com/cypht-org/cypht/pull/1044 be held back?
@josaphatim please release Cypht 2.1.0
@rodriguezny commented on GitHub (May 25, 2024):
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.
@rodriguezny commented on GitHub (May 25, 2024):
Thanks for the new image posted, we can now update sailfrog image readme to point to https://hub.docker.com/u/cypht.
@jonocodes commented on GitHub (May 25, 2024):
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.
@jonocodes commented on GitHub (May 25, 2024):
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.
@marclaporte commented on GitHub (May 25, 2024):
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
@marclaporte commented on GitHub (May 25, 2024):
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!
@marclaporte commented on GitHub (May 26, 2024):
Also to do: update instructions on https://www.cypht.org/install-2x.html
@rodriguezny commented on GitHub (May 26, 2024):
@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.
@jonocodes commented on GitHub (May 26, 2024):
OK. Perhaps wait to announce until we have a proper tag in the new repo.
@marclaporte commented on GitHub (May 27, 2024):
ok, I pointed people here so they get latest status
@rodriguezny commented on GitHub (May 27, 2024):
https://github.com/cypht-org/cypht-website/pull/60
@jonocodes commented on GitHub (May 28, 2024):
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.
@jonocodes commented on GitHub (May 29, 2024):
This updates old references:
https://github.com/cypht-org/cypht/pull/1053
Not sure what the PR review policy before merging is.
@marclaporte commented on GitHub (May 29, 2024):
In general, let someone else review and merge. But if you are confident it's low risk, you can merge it yourself.
@marclaporte commented on GitHub (Jun 13, 2024):
@rodriguezny Can we have a nice logo on https://hub.docker.com/r/cypht/cypht ?
@rodriguezny commented on GitHub (Jun 13, 2024):
Yes, we can. Let me update it.
@rodriguezny commented on GitHub (Jun 13, 2024):
Done!
@marclaporte commented on GitHub (Jun 18, 2024):
@jonocodes: Can we please have a new tag for https://github.com/cypht-org/cypht/releases/tag/v2.1.0? (now requires PHP 8.1)
Thanks!
@marclaporte commented on GitHub (Jun 18, 2024):
@rodriguezny We have 944 stars on https://github.com/cypht-org/cypht but only 2 on https://hub.docker.com/r/cypht/cypht
Any ideas?
@rodriguezny commented on GitHub (Jun 18, 2024):
I think the fact is that not every github user or every community member has a dockerhub account. In the 2 stars, there is one of mine and the other one should be for @jonocodes or you or any one else. Let's remember community members to give us a star.
@marclaporte commented on GitHub (Jun 18, 2024):
Oh! I thought it grabbed the stars from GitHub :-)
@jonocodes commented on GitHub (Jun 18, 2024):
Yes, 2.1.0 is now in docker hub.
Also I just added instructions so others know how to do the release:
https://github.com/cypht-org/cypht/wiki/How-to-release-Cypht#manually-releasing-a-docker-image
Side note: I think it would be nice to surface the version number either in the UI or in the HTML source to help with debugging user issues.
@marclaporte commented on GitHub (Jun 19, 2024):
Done: https://github.com/cypht-org/cypht/pull/594
@jonocodes commented on GitHub (Jun 19, 2024):
I think whats here is a good starting point. But it is focused on development.
a) I dont know how to enable it or where to find it displayed
b) I dont think it will display the tag version. only the checksum
c) I dont think it will work in docker since there is no git there
Ideally this would be shown to all users in production as a version number like 2.1.0
@marclaporte commented on GitHub (Jun 19, 2024):
Agreed. Can you please add?
@marclaporte commented on GitHub (Jun 19, 2024):
@jonocodes The front page of https://hub.docker.com/r/cypht/cypht still mentions PHP 7. Maybe best to remove version number since it can vary?
@jonocodes commented on GitHub (Jun 19, 2024):
Lets make a ticket. It will take some work to sort out because we are going to have to write the version number to a file somewhere probably.
@jonocodes commented on GitHub (Jun 19, 2024):
Updated. And now there are instructions in the wiki
https://github.com/cypht-org/cypht/wiki/How-to-release-Cypht#updating-readme-in-dockerhub
@marclaporte commented on GitHub (Jul 14, 2024):
@rodriguezny what is left to do here, if anything?
@rodriguezny commented on GitHub (Jul 14, 2024):
AFAIK, nothing is left. Unless @jonocodes says other thing.
@jonocodes commented on GitHub (Jul 15, 2024):
Looks good to me. Thanks.