The next major version and workflow (Proposal)

[ikedas]

I was going to submit this proposal after 6.2.70 was released, but since I don't know when that will be, I am submitting it now.

The next major version

Version 7 has been talked about as the next major version for the past few years, but it should be officially withdrawn. The reason is that little substantive works were done. All proposals that were supposed to be included in version 7 (e.g., the new logo) will be scrapped because time is running out.

It is proposed that next major version be 8, and works should begin on a new 8.0.0 release. However about support policies see below.

Version 8.0.0

8.0.0 is essentially an extension of the current Sympa. That is, once some of the proposed additions and changes have been resolved, we will declare 8.0.0 (Details will be discussed separately).

Workflow

There has been no formal agreement on the workflow for Sympa development, but based on our practice over the past several years, I propose that it be as follows:

• Follow a restricted GitHub flow.

The difference from the general GitHub flow is that "feature branches" and "release branches" will not be created in the main repository (sympa-community/sympa.git).

• The changes for feature additions and bug fixing are done by submitting pull requests. Each fork has its own working branch, not the main repository.

  (Note: Major changes that cannot be handled by a PR should be split into multiple PRs or made into a separate project from the beginning.)

• No separate branches for each release. New releases are done simply by pushing tags to the main branch. Do not continue to maintain past versions (e.g., previous minor versions)

As a result, the main repository will have only one main branch and some branches for planned routine works.

• The main branch will be main (which sympa-6.2 may be renamed to), and the master branch will not be used anymore.

• Branches for planned routine works may be added as needed. Currently there are translation (importing update on translation site) and pr/release-x.x.x (building release notes).

Incidentally, for this workflow to be effective, it will be important to simplify and automate the release process.

Support policies

After the next major release, the support policy should be as follows

• No fixes will be provided for previous versions, except for critical security issues. The latest release will always be the recommended version.

• Ensure backward compatibility with the previous minor version or provide a means of migration from it. More earlier versions will not be supported.
  That is, 8.0.x supports only 6.2.x, 8.1.x supports only 8.0.x and so on.

[ikedas]

@everyone,
My personal goal with the proposal above is that stated in the "Support Policy" section: To clarify EOL and discontinue support for older versions.

If there are no particular objections, I'll implement the proposal, i.e.:

• Move the main branch from sympa-6.2, the actual main branch, to main and announce it.
• Post the support policy on the website.

[ikedas]

Now the default branch is main.

In addition, a PR is now required for merging into the main branch.

[racke]

Good 👍 How do I get the main branch into my fork?

[ldidry]

You can do, in the repository on your computer:

git remote add upstream github.com/sympa-community/sympa/
git fetch upstream
git checkout -b main upstream/main
git push -u origin main

It will create a main branch in your local repository, push it to your fork (origin) and set this branch to push to origin/main by default.

[racke]

Thanks!