Back to master/main ... but how?

[cehbrecht]

Description

We should get master working again soon.

How can we do this?

Option 1 (easy):

• make a new branch main from pywps-4.4
• main becomes the default branch
• freeze master - read-only
• main becomes version 4.6 (following the tradition ... we might skip it with 5.x)

Option 2:

• merge pywps-4.4 to master
• keep complete history of pywps-4.4 ... no squash
• the version on master should than be the same as on pywps-4.4
• what are the clever git commands here?
• master becomes version 4.6 (following the tradition ... we might skip it with 5.x)

Environment

• operating system:
• Python version:
• PyWPS version: 4.4
• source/distribution
• [ ] git clone
• [ ] Debian
• [ ] PyPI
• [ ] zip/tar.gz
• [ ] other (please specify):
• web server
• [ ] Apache/mod_wsgi
• [ ] CGI
• [ ] other (please specify):

Steps to Reproduce

Additional Information

See discussion in #568

[fmigneault]

IMHO, I would avoid having both master and main. It will just make things even more confusing. I find the versioning method skipping odd minor number already hard to follow as it is.

[tomkralidis]

IMHO, I would avoid having both master and main. It will just make things even more confusing.

+1, either master or main but not both

I find the versioning method skipping odd minor number already hard to follow as it is.

The even/odd strategy comes from Fogel and is used by various FOSS4G projects.

[fmigneault]

The even/odd strategy comes from Fogel and is used by various FOSS4G projects.

I can see the use case for Linux being such a large code base and where it comes from, but it clearly isn't used here. Otherwise, there wouldn't even be this issue of syncing master, 4.4 and eventual 4.6. It would just be 4.5 directly.

I find most python packages use the typical semver method where major is for big/breaking changes, minor is a new feature, and patch for fixes. This is actually the only python package I'm aware of that uses this even/odd method.

[cehbrecht]

Should we break the tradition and aim for a 4.5 release? Or should we do this starting with 5.x (ogcapi, ...)

I need to figure out the "clever" git commands to get pywps-4.4 merged into master. Maybe someone has already an idea ...

[ldesousa]

Hi all,

Let us leave the odd/even question aside for now. If this is a relavant topic please open a new issue. Here we should focus on fixing the master branch, we can discuss version numbering for the 5.x.x series.

Would this third option work?

1. Set pywps-4.4 as default branch
2. Delete master (local and origin)
3. Create a new master branch locally
4. Merge pywps-4.4 into new master and push to origin
5. Set master again as default branch

I am not sure of all the consequences (e.g. tags). If this is not outright dumb I will make some experiments with a dummy repository once I get better.

Cheers.

[cehbrecht]

Hi all,

Let us leave the odd/even question aside for now. If this is a relavant topic please open a new issue. Here we should focus on fixing the master branch, we can discuss version numbering for the 5.x.x series.

Would this third option work?

1. Set pywps-4.4 as default branch

2. Delete master (local and origin)

3. Create a new master branch locally

4. Merge pywps-4.4 into new master and push to origin

5. Set master again as default branch

I am not sure of all the consequences (e.g. tags). If this is not outright dumb I will make some experiments with a dummy repository once I get better.

Cheers.

I would call the new "master" main.

Instead of deleting the current "master" we could rename it ... dev-jobqueue-old ???

[ldesousa]

I would call the new "master" main.

Instead of deleting the current "master" we could rename it ... dev-jobqueue-old ???

Fine for me, as long as we don't have both master and main.

[fmigneault]

For rename, it is probably better to use github's utility in repo settings. It helps older references (aka possibly in other repos, configs, et.c pointing to pywps) to redirect master to main. Delete/create of the branch by hand might raise issues

[idanmiara]

I've compared the history of 4.4 and Master, They diverged just after 4.2.4. The are only 5 commits to Master that are missing from 4.4. The other commits seemed to be cherry picked to 4.4. The 5 missing commits and their authors are: 1 jobqueue-505 @jachym @cehbrecht 2 Issue-516-docs-config-518 @cehbrecht 3 Issue-531-configparser-with-encoding-532 @cehbrecht 4 Added-validation-for-GPX-files-fixes-issue-535 @kvold 5 documentation-updates @jachym

I've tried to merge and/or rebase between the two branches, but it was not trivial. Since 4.4 includes many more extra commits than Master - I suggest that the authors of the commits above will cherry pick them onto 4.4 and then we'll reintroduce 4.4 as the new Master.

[cehbrecht]

I've compared the history of 4.4 and Master, They diverged just after 4.2.4. The are only 5 commits to Master that are missing from 4.4. The other commits seemed to be cherry picked to 4.4. The 5 missing commits and their authors are: 1 jobqueue-505 @jachym @cehbrecht 2 Issue-516-docs-config-518 @cehbrecht 3 Issue-531-configparser-with-encoding-532 @cehbrecht 4 Added-validation-for-GPX-files-fixes-issue-535 @kvold 5 documentation-updates @jachym

I've tried to merge and/or rebase between the two branches, but it was not trivial. Since 4.4 includes many more extra commits than Master - I suggest that the authors of the commits above will cherry pick them onto 4.4 and then we'll reintroduce 4.4 as the new Master.

@idanmiara Thanks for looking at this. Commits were skipped intentionally to avoid the job-queue. But not sure if there are still a few things that we should bring to pywps-4.4.

[Zeitsperre]

Hey all, I really like @ldesousa's proposal for migrating pywps-4.4 to become the new main and @fmigneault's suggestion to use the renaming utility would reduce the risk of breakages with any current branches/dev efforts outside this immediate group.

For the job queue stuff, I'm not at all knowledgeable, but it's clear that there is a need to port at least some of it. I leave you to determine how best to do that.

For versioning, I don't think we need to stick with tradition if we want to abandon it in 4.x, but that's just my opinion. Version 5.x should follow a typical semver approach.

In order to no longer have this problem, would it make sense to tag new versions from main from now on? Ask that changes on master pass tests and tag commits as versions based off of it? Thoughts?

[cehbrecht]

Procedure to get to new main branch:

1. Set pywps-4.4 as default branch (we can do it already)
2. Create a new main branch from pywps-4.4
3. Rename master to dev-jobqueue-old (using github tools)
4. Make dev-jobqueue-old (previous master) read-only
5. Set main as default branch
6. Set version 4.5.x on main
7. Integrate PRs from "old master" if necessary ... probably we don't need this

@ldesousa @jachym @fmigneault @Zeitsperre @tomkralidis agree?

[ldesousa]

@cehbrecht This procedure makes sense. I do not expect any of this to affect the tags already in place. Renaming with GitHub will also make sure old URLs remain valid.

Please go ahead.

[cehbrecht]

Checklist to get to new main branch:

• [x] Set pywps-4.4 as default branch (we can do it already)
• [x] Create a new main branch from pywps-4.4
• [x] Rename master to dev-jobqueue-old (using github tools)
• [ ] Make dev-jobqueue-old (previous master) read-only
• [x] Set main as default branch
• [ ] Set version 4.5.x on main
• [ ] Integrate PRs from "old master" if necessary ... probably we don't need this

[idanmiara]

Checklist to get to new main branch:

• [x] Set pywps-4.4 as default branch (we can do it already)
• [ ] Create a new main branch from pywps-4.4
• [ ] Rename master to dev-jobqueue-old (using github tools)
• [ ] Make dev-jobqueue-old (previous master) read-only
• [ ] Set main as default branch
• [ ] Set version 4.5.x on main
• [ ] Integrate PRs from "old master" if necessary ... probably we don't need this

Do you want help with any of this?

[cehbrecht]

@idanmiara thanks :) Not yet ... I will do a final release of pywps 4.4 and then proceed with the main branch.

[cehbrecht]

The main branch is now the default branch. It is currently the same as the pywps-4.4 branch.

[cehbrecht]

The master branch was renamed to dev-jobqueue-old. The renaming will not automatically happen in your local repos. You need to do the following:

git branch -m master dev-jobqueue-old
git fetch origin
git branch -u origin/dev-jobqueue-old dev-jobqueue-old