Hi all,
It's been a little while without much activity in this thread and I
wanted to make sure the ball is still rolling here.
I've reviewed in detail the policy statement here[0], and can see there
may be some gaps we need to cover or understand better how we are going
to go about officiating any release.
In general from what I can understand, the process is fairly straight
forward:
o A release is proposed on this archived mailing list
o Three team members (and at least a majority) must give their +1
to approve the release
o The approved release tarball is then cryptographically signed
and uploaded to downloads.apache.org
One of the obstacles I can see here, is in the "RELEASE APPROVAL"
section it is stated:
"individuals are REQUIRED to download all signed source code
packages onto their own hardware, verify that they meet all
requirements of ASF policy on releases as described below"
This seems a bit dated to me, should we be creating tarballs with
`python3 setup.py sdist` and signing them and uploading them to some
location ?
Perhaps in 2022, it should be sufficient to create a signed git tag for
other core developers to checkout and run `tox` against on their own
machines ?
Further, I should note that voting on an EXACT version or tarball for a
release does not make sense for us, as we will need to TAG the official
release AFTER it is finally approved, and doing so will effectively
alter the generated output of a release tarball due to the version
number change.
For right now, we really need to get an official "Beta" release out if
only to signify that by now, the API is officially frozen and shall not
be broken (while it *may* be extended in advance of a 2.0 final
release).
What do we need to do to make this happen ? Should I propose the
current tip of the master branch
(d796c4e079b3bb5c85e4c3adf87c86e3cfa4d76a) as the beta release ?
Any thoughts and input on this would be greatly appreciated to help us
get the ball rolling here.
Cheers,
-Tristan
[0]: https://www.apache.org/legal/release-policy.html
On Mon, 2022-04-25 at 17:44 +0900, Tristan Van Berkom wrote:
> Hi,
>
> All of the outstanding issues on the milestone[0] which came out
> of
> our last meeting[1] have been take care of, including removing the
> last
> plugins out of the buildstream repository and adding them to the new
> buildstream-plugins[2] repository (which also includes the plugins we
> agreed to add from other repositories such as bst-plugins-container
> and
> bst-plugins-experimental).
>
> As such, I propose that we declare the API to be stable, and make an
> initial beta release of buildstream & buildstream-plugins to signify
> this API stability cutoff.
>
> After this, we still have some road to travel to assist the
> freedesktop-sdk project to migrate[3] to BuildStream 2, which will be
> a
> great help in assisting us to find and fix any remaining issue before
> we can finally reach a formal BuildStream 2.0 release, for which
> we've
> already created another milestone[4].
>
> This email is a sanity check:
>
> * Have we missed any critical issues which must be fixed and cannot
> be fixed without breaking API ?
>
> * Are there any reasons to delay declaring the API surfaces for
> BuildStream (and buildstream-plugins) as stable ?
>
> So long as there are no reasons to block this, I will be looking into
> how the release process should work within our new home at Apache and
> hopefully we can get passed this important milestone soon.
>
> Cheers,
> -Tristan
>
> [0]: https://github.com/apache/buildstream/milestone/2
> [1]: https://lists.apache.org/thread/d7fgbdnfx62b4v1mz8g8qq56ohm3kjmz
> [2]: https://github.com/apache/buildstream-plugins
> [3]: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1383
> [4]: https://github.com/apache/buildstream/milestone/3
>
>
>
