Make ACA-Py 1.6 an LTS release - #4127
Conversation
Signed-off-by: Stephen Curran <swcurran@gmail.com>
Signed-off-by: Stephen Curran <swcurran@gmail.com>
|
@esune -- added 1.6 to the lts-versions.txt file, and then deleted/recreated the 1.6.lts branch. Let me know if that resulted in the correct tags happening for the 1.6.lts. Not crucial if not, but it would be nice. Once we get to 1.7 and 1.6.lts doesn't move along main, all will be well. |
|
|
Doh...without this PR merged, creating/deleting the branch won't do anything... |
There was a problem hiding this comment.
Changes look good! Yes, updating the version in the versions file is the only thing you need to do to track the new LTS releases. And you are correct that we will not see any change until this is merged AND a new release is created for 1.6 (tags on images are rolling so will just point to the newest one).
|
I think the steps in the Publishing are right for while we have 1.6.x as the current release and LTS:
Once 1.7 or 2.0 (whichever is next) is released, 1.6.lts expands via cherry-picked PRs, separate from main. |
3 participants
Updates ACA-Py LTS releases to make 1.6 the current LTS and sets the end-of-life for the 1.3 LTS to January, 2027. Agreement to declare 1.6 the current LTS release was made at the ACA-Pug meeting on 2026.04.28.
Updated the publishing instructions (Publishing.md) to note how to handled the situation that we have now with the LTS version also being the current version. During such times, the LTS branch (e.g., 1.6.lts) must be updated to match the release commit on main for new releases until we have a new version (e.g., 1.7.0 or 2.0.0). That should trigger the LTS container to be built at the correct commit.
@esune -- please review updates to lts-versions.txt, and check if the proper LTS tagging was done. I'm guessing not because I didn't have the lts-versions.txt including 1.6 when I create the 1.6.lts branch. Let's collaborate.