search

geopython / pywps

PyWPS is an implementation of the Web Processing Service standard from the Open Geospatial Consortium. PyWPS is written in Python.
https://pywps.org
MIT License
178 stars 117 forks source link

Back to master/main ... but how? #590

Closed cehbrecht closed 1 year ago

cehbrecht commented 3 years ago

Description

We should get master working again soon.

How can we do this?

Option 1 (easy):

Option 2:

Environment

Steps to Reproduce

Additional Information

See discussion in #568

fmigneault commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

Checklist to get to new main branch:

idanmiara commented 3 years ago

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 commented 3 years ago

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

cehbrecht commented 3 years ago

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

cehbrecht commented 3 years ago

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