build: extend release information and layout
This extends on our model how we do releases. It introduces `NEWS.md` as the authoritative source of our release-notes. It is pre-populated with the release-notes from the previous 'v9' release, and contains a suggestion for the upcoming 'v10'. Furthermore, this adds `make release` as a simple checklist target that contains instructions how to create a new release. Note that it is a passive make-target which has no side-effects at all. It only prints release information. With this in place, we can drop `RELEASE.md`, as all information is now combined in `make release`.
This commit is contained in:
David Rheinsberg
parent
1ab282b906
commit
22eeb9a095
3 changed files with 133 additions and 23 deletions
57
Makefile
57
Makefile
|
|
@ -145,3 +145,60 @@ bump-version:
|
|||
sed -i "s|Version:\(\s*\)$(VERSION)|Version:\1$(NEXT_VERSION)|" osbuild.spec
|
||||
sed -i "s|Release:\(\s*\)[[:digit:]]\+|Release:\11|" osbuild.spec
|
||||
sed -i "s|version=\"$(VERSION)\"|version=\"$(NEXT_VERSION)\"|" setup.py
|
||||
|
||||
.PHONY: release
|
||||
release:
|
||||
@echo
|
||||
@echo "Checklist for release of osbuild-$(NEXT_VERSION):"
|
||||
@echo
|
||||
@echo " * Create news entry in NEWS.md with a short description of"
|
||||
@echo " any changes since the last release, which are relevant to"
|
||||
@echo " users, packagers, distributors, or dependent projects."
|
||||
@echo
|
||||
@echo " Use the following template, break lines at 80ch:"
|
||||
@echo
|
||||
@echo "--------------------------------------------------------------------------------"
|
||||
@echo "## CHANGES WITH $(NEXT_VERSION):"
|
||||
@echo
|
||||
@echo " * ..."
|
||||
@echo
|
||||
@echo " * ..."
|
||||
@echo
|
||||
@echo -n " Contributions from: "
|
||||
@echo `git log --format='%an, ' v$(VERSION)..HEAD | sort -u | tr -d '\n' | sed 's/, $$//'`
|
||||
@echo
|
||||
@echo " - Location, YYYY-MM-DD"
|
||||
@echo "--------------------------------------------------------------------------------"
|
||||
@echo
|
||||
@echo " To get a list of changes since the last release, you may use:"
|
||||
@echo
|
||||
@echo " git log v$(VERSION)..HEAD"
|
||||
@echo
|
||||
@echo " * Bump the project version. The canonical location is"
|
||||
@echo " 'setup.py', but 'osbuild.spec' needs to be updated as well."
|
||||
@echo " You can use the following make-target to automate this:"
|
||||
@echo
|
||||
@echo " make bump-version"
|
||||
@echo
|
||||
@echo " * Make sure the spec-file is updated for the new release and"
|
||||
@echo " correctly supports all new features. This should already be"
|
||||
@echo " done by previous commits that introduced the changes, but"
|
||||
@echo " a sanity check does not hurt."
|
||||
@echo
|
||||
@echo " * Commit the version bump, spec-file changes and NEWS.md in any"
|
||||
@echo " order you want."
|
||||
@echo
|
||||
@echo " * Tag the release via:"
|
||||
@echo
|
||||
@echo " git tag -s -m 'osbuild $(NEXT_VERSION)' v$(NEXT_VERSION) HEAD"
|
||||
@echo
|
||||
@echo " * Push master as well as the tag:"
|
||||
@echo
|
||||
@echo " git push origin master"
|
||||
@echo " git push origin v$(NEXT_VERSION)"
|
||||
@echo
|
||||
@echo " * Create a release on github. Use 'NEWS.md' verbatim from the"
|
||||
@echo " top until the end of the section for this release as release"
|
||||
@echo " notes. Use 'v$(NEXT_VERSION)' as release name and as tag for"
|
||||
@echo " the release."
|
||||
@echo
|
||||
|
|
|
|||
76
NEWS.md
Normal file
76
NEWS.md
Normal file
|
|
@ -0,0 +1,76 @@
|
|||
# OSBuild - Build-Pipelines for Operating System Artifacts
|
||||
|
||||
## CHANGES WITH 10:
|
||||
|
||||
* A new man-page `osbuild-manifest(5)` is available, which describes
|
||||
the input format of the JSON manifest that `osbuild` expects.
|
||||
|
||||
* Man-pages can now be built via `make man`. This supports `SRCDIR` and
|
||||
`BUILDDIR` variables to build out-of-tree.
|
||||
|
||||
* Temporary objects in the object-store are now created in
|
||||
`.osbuild/tmp/`, rather than in the top-level directory. This should
|
||||
help cleaning up temporary objects after a crash. If no osbuild
|
||||
process is running, the `tmp/` subdirectory should not exist.
|
||||
|
||||
* The final stage of a build-pipeline is no longer automatically
|
||||
committed. You must pass checkpoints via `--checkpoint` to commit
|
||||
anything to the store.
|
||||
|
||||
* Improve curl timeout handling. This should improve osbuild behavior
|
||||
with slow or bad mirrors and make sure operations are retried
|
||||
correctly, or time-out if no progress is made.
|
||||
|
||||
Contributions from: Christian Kellner, David Rheinsberg, Lars Karlitski,
|
||||
Major Hayden, Tom Gundersen
|
||||
|
||||
- Berlin, 2020-03-18
|
||||
|
||||
## CHANGES WITH 9:
|
||||
|
||||
* The last pipeline stage is no longer automatically committed to the
|
||||
store. This used to be a special case to make things work, but it has
|
||||
now been properly fixed.
|
||||
From now on, if you want a stage committed to the store, you need to
|
||||
pass a `--checkpoint` option for the stage.
|
||||
|
||||
* The runner for the host system is now auto-detected. The
|
||||
`runners/org.osbuild.default` symlink is now longer required (nor
|
||||
supported).
|
||||
|
||||
* A generic runner named `org.osbuild.linux` was added. This runner
|
||||
uses the default value of `ID` in `/etc/os-release`. That is, if the
|
||||
local OS cannot be detected, or if no `os-release` file is provided,
|
||||
this is the fallback runner that is used.
|
||||
This runner only performs the bare minimum of initialization. It is
|
||||
enough to run the most basic stages on all systems we tested.
|
||||
|
||||
* On Archlinux, the generic runner will now be used.
|
||||
|
||||
* A new runner for RHEL-8.1 is available.
|
||||
|
||||
* The JSON input to `osbuild` is now a monolithic manifest format which
|
||||
contains all build information. For now, this means the input
|
||||
manifest can contain a `pipeline:` key with the pipeline definition,
|
||||
as well as a `sources:` key with external source definitions
|
||||
previously passed via `--sources`.
|
||||
The old input format is still supported, but will be dropped in the
|
||||
next release.
|
||||
|
||||
* The osbuild sources now come with a man-page `osbuild(1)`. Further
|
||||
pages will follow in the future.
|
||||
|
||||
Contributions from: Christian Kellner, David Rheinsberg, Jacob Kozol,
|
||||
Lars Karlitski, Major Hayden, Martin Sehnoutka, Tom
|
||||
Gundersen
|
||||
|
||||
- Berlin, 2020-03-05
|
||||
|
||||
## CHANGES BEFORE 9:
|
||||
|
||||
* Initial implementation of 'osbuild'.
|
||||
|
||||
Contributions from: Brian C. Lane, Christian Kellner, David Rheinsberg,
|
||||
Jacob Kozol, Lars Karlitski, Major Hayden, Martin
|
||||
Sehnoutka, Ondřej Budai, Sehny, Tom Gundersen,
|
||||
Tomas Tomecek, Will Woods
|
||||
23
RELEASE.md
23
RELEASE.md
|
|
@ -1,23 +0,0 @@
|
|||
# How to create new release
|
||||
|
||||
Use the `bump-version` target to bump the version:
|
||||
|
||||
```
|
||||
$ make bump-version
|
||||
```
|
||||
Check that the spec file is correctly modified.
|
||||
Create new commit from this change; this commit will become the new tag.
|
||||
The name of the tag should the be the new version number prefixed by `v`.
|
||||
```
|
||||
$ git tag -a v<version-number> -m <some description>
|
||||
$ git push origin <version-number>
|
||||
```
|
||||
|
||||
|
||||
Create new release on Github containing the number of this release as its
|
||||
name, the same number as a tag, and description copied from the previous
|
||||
one.
|
||||
|
||||
|
||||
Once the Github release is available, follow the standard procedure for
|
||||
creating a Fedora update.
|
||||
Loading…
Add table
Add a link
Reference in a new issue