Skip to content

Release 2.26.0 #7895

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

Closed
wants to merge 6 commits into from
Closed

Release 2.26.0 #7895

wants to merge 6 commits into from

Conversation

petersmythe
Copy link
Contributor

@petersmythe petersmythe commented Sep 16, 2024

Pulling together the following:

Of interest - ignore the following failure:

Checklist

For core and extension modules:

  • New unit tests have been added covering the changes.
  • Documentation has been updated (if change is visible to end users).
  • The REST API docs have been updated (when changing configuration objects or the REST controllers).
  • There is an issue in the GeoServer Jira (except for changes that do not affect administrators or end users in any way).
  • Commit message(s) must be in the form [GEOS-XYZWV] Title of the Jira ticket.
  • Bug fixes and small new features are presented as a single commit.
  • Each commit has a single objective (if there are multiple commits, each has a separate JIRA ticket describing its goal).

@@ -102,7 +102,7 @@ When creating the first release candidate of a series, there are some extra step

ant -f build/rename.xml

.. note:: use of sed
.. note:: Alternative use of sed
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this whole note not simply be removed, or do some people still prefer sed over build/rename.xml?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the rename.xml scrip is working for you; then yes we could remove the manual sed instructions now.

* create new jobs, copying from the existing stable jobs, and edit the branch.
* modify the last line of the live-docs builds, changing ``stable`` to ``maintain`` for the previous stable branch. The new job you created should publish to ``stable``, and the main development branch will continue to publish to ``latest``.
* create new jobs, duplicating from the three existing stable jobs (geoserver-2.11.x, geoserver-2.11.x-docs and geoserver-2.11.x-nightly), and edit the branch specifier to the new branch (e.g. `2.11.x` -> `2.12.x`).
* delete the trigger on the previous `geoserver-2.11.x-nightly` job to not trigger the `geoserver-release-docker` job
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this needs to be added @jodygarnett ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think personally I open up all the jobs as distinct tabs, "disable them", and then update the code, and then enable first geotools, then geowebcache, then geoserver (to avoid overloading build server).

The alternative is killing lots of jobs so the one you are working on has a chance to run.


* Update the cite tests on build.geoserver.org:
* ~~Update the cite tests on build.geoserver.org~~:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leave this here in the hopes that we will one day return to cite tests?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe marked as "not currently used", but I have stopped trying to promote cite tests as a sponsorship target.

@@ -155,8 +155,6 @@ When creating the first release candidate of a series, there are some extra step
* Switch to the new branch and update the documentation links, replacing ``docs.geoserver.org/latest`` with ``docs.geoserver.org/2.12.x`` (for example):

* ``README.md``
* ``doc/en/developer/source/conf.py``
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the ant build/rename.xml has already updated these 2 conf.py files, hasn't it @jodygarnett ?

Does the README.md still need to be changed - probably yes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope the rename.xml does what is needed. But I still wish to document the manual process (if needed).

@petersmythe
Copy link
Contributor Author

petersmythe commented Sep 16, 2024

Depends on geotools/geotools#4904 and GWC new snapshots being available

@jodygarnett
Copy link
Member

@petersmythe I have my own notes from the release process to share. Can we untangle the developers guide improvements from the creation of 2.27-SNAPSHOT?

  • No longer any need to enable branch protection
  • Use include to pull the example lines from build.xml
  • Update index.html
        <dl>
          <dt>GeoServer 2.21.x
              ( <a href="https://docs.geoserver.org/2.21.x/en/user/">User Manual</a>
              | <a href="https://docs.geoserver.org/2.21.x/en/developer/">Developer Manual</a>
              | <a href="https://docs.geoserver.org/2.21.x/en/docguide/">Documentation Guide<a/>
              )
          </dt>
        </dl>
    
  • Create next major release in Jira (removing references to RC)
  • Disable the maintenance jobs? Leave the maintenance jobs around for a bit, they only run if someone back ports a change.
Update the doc snippet at the end...
  • Disable all the jobs so you can test in isolation (open them all in multiple tabs to ease frustration)
  • Maintenance -> archive
    • 2.24.x - no change needed
    • 2.24.x-docs - 
# Change this when releasing
# LINK=maintain
# LINK_PATH=/var/www/geoserverdocs/$LINK
...
# echo "link $VER to $LINK_PATH"
# ssh -oStrictHostKeyChecking=no -p 2223 $REMOTE "if [ -e $LINK_PATH ]; then rm $LINK_PATH; fi && ln -s $REMOTE_PATH $LINK_PATH"
#
# echo "docs published to https://docs.geoserver.org/$LINK/en/user"
    • 2.24.x-nightly - uses scp to copy to 2.24.x folder (so there must be a symbolic link on docs.geoserver?)
  • Stable to maintain
    • 2.25.x - no change needed
    • 2.25.x-docs
LINK=maintain
    • 2.25.x-nightly - no change needed
  • Dev to stable
    • 2.26.x - copied from 2.25.x (changing to 2.25.x)
update 2.25.x --> 2.26.x
    • 2.26.x-docs - copied from 2.25.x-docs (changing to 2.25.x) 
LINK=stable
    • 2.26.x-nightly - copied from 2.25.x-nightly (changing to 2.25.x)
  • Dev
    • Can now run to test out the new dependencies
  • Docker - need to update the Dockerfile
  • Remove reference to the cite tests

Copy link

stale bot commented Dec 28, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Dec 28, 2024
Copy link

stale bot commented Jan 11, 2025

This issue has been automatically closed because it has not had recent activity. Please re-submit with updates if you want to resume work on this topic. Thank you for your contributions.

@stale stale bot closed this Jan 11, 2025
@petersmythe petersmythe deleted the peter-release-v2.26.0 branch February 19, 2025 10:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants