Commit 08347725 authored by Dan Villiom Podlaski Christiansen's avatar Dan Villiom Podlaski Christiansen
Browse files

versioning: create branch 1.0.x

The upcoming release will be called 1.0 rather than 0.11.0. The main
motivation for this is that I consider hg-git “ready”. In order for
semantic versioning to make sense, something has to eventually be good
enough. With the changes to user experience, I personally consider
this good enough to actually use. And besides, if this isn't 1.0, when
should it be? When development ceases?

I've updated `CONTRIBUTING.rst` to specify an explicit compatibility
policy.
parent 729775377f6b
Pipeline #31575 passed with stages
in 25 minutes and 5 seconds
......@@ -17,7 +17,6 @@
Long version
------------
We use a variant of Mercurial's `own contribution system
<https://www.mercurial-scm.org/wiki/ContributingChanges>`_. Key
We use a variant of Mercurial's `own contribution guidelines`_. Key
differences are (by rule number):
......@@ -22,5 +21,8 @@
differences are (by rule number):
.. _own contribution guidelines:
https://www.mercurial-scm.org/wiki/ContributingChanges
2
You can cross-reference Heptapod issues in the ``#NNN`` format.
......@@ -24,7 +26,10 @@
2
You can cross-reference Heptapod issues in the ``#NNN`` format.
10
We use mostly pep8 style. The current codebase is a mess, but new
code should be basically pep8.
To submit a Merge Request, please ask for Developer rights using the
`Request access`_ link. We usually respond to that relatively quickly,
but you can expedite the request by sending a mail to the list. Please
note that we generally do a quick cursory check of people requesting
access to ensure that there's a human at the other end. Then,
following the instructions of the `Heptapod tutorial`_ should be enough.
......@@ -30,12 +35,9 @@
To submit a Merge Request, please ask for Developer rights using the
*Request access* link. We usually respond to that relatively quickly,
but you can expedite the request by sending a mail to the list. Then,
following the instructions of the following tutorial should be enough:
https://heptapod.net/pages/quick-start-guide.html
.. _Request access:
https://foss.heptapod.net/mercurial/hg-git/-/project_members/request_access
.. _Heptapod tutorial: https://heptapod.net/pages/quick-start-guide.html
If you do a merge request, we're still going to expect you to
provide a clean history, and to be willing to rework history so it's
clean before we push the "merge" button. If you're uncomfortable with
history editing, we'll clean up the commits before merging.
......@@ -37,5 +39,38 @@
If you do a merge request, we're still going to expect you to
provide a clean history, and to be willing to rework history so it's
clean before we push the "merge" button. If you're uncomfortable with
history editing, we'll clean up the commits before merging.
Compatibility policy
--------------------
We generally follow `semantic versioning`_ guidelines: Major releases,
that is ``x.0.0``, are for significant changes to user experience,
especially new features or changes likely to affect workflow. Minor
releases, ``x.y.0``, are for less significant changes or adjustments
to user experience, including bug fixes, but they needn't retain
_exact_ compatibility. Patch releases, ``x.y.z``, are exclusively for
breaking bugs and compatibility.
.. _semantic versioning: https://semver.org
We can drop compatibility for unsupported versions of Python,
Mercurial or Dulwich in anything but patch releases.
There is no fixed policy for which versions of Mercurial and Dulwich
we support, but as loose guideline, versions prior to the version
that ships in the latest Ubuntu LTS release may be dropped if they are
older than a year and interfere with new development. Unfortunately,
due to dropping support for Python 2.7, hg-git does not work on any
shipped Ubuntu LTS, as-is, since 20.04 used 5.3.1 on Python 2.7, but
only shipped Dulwich for Python 3.6. Once 22.04 is out, that will be
our bare minimum.
We commit to supporting any version of Python at least as long as it
receives security updates from ``python.org``, unless it conflicts
with the requirements of a supported Ubuntu LTS.
The authoritative source for dependency requirements is
``.gitlab-ci.yml``, although ``setup.cfg`` and ``hggit/__init__.py``
also list them.
......@@ -422,5 +422,5 @@
[hggit]
invalidpaths = keep
Possible values are ``keep``, ``skip`` or ``abort``. Prior to 0.11,
Possible values are ``keep``, ``skip`` or ``abort``. Prior to 1.0,
the default was ``abort``.
......@@ -124,7 +124,7 @@
``ui``:
``abort`` means insecure paths abort the conversion —
this was the default prior to 0.11.
this was the default prior to 1.0.
``keep`` means issue a warning and keep the path,
returning ``True``.
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment