Hey Jason, We've been tagging release candidates as a.b.c-rcN. Once a release is voted on, we create an a.b.c tag. IIUC your script can use this instead of an a.b.x branch. We prefer tags to branches for their immutable semantics (assuming you don't delete and re-push a tag, which we've been doing *only before announcing* a tag, but can stop if your script expects otherwise).
As for building a package for the master branch, I'd like to propose a versioning scheme that includes the date, i.e., 0.14.0-20130806 (a.b.c-YYYYMMDD). This limits the packages to one per day but has a nice monotonically increasing value property for finding the latest (and is easy to reason about). Ben. On Tue, Aug 6, 2013 at 11:53 AM, Jason Dusek <[email protected]> wrote: > 2013/8/6 Dave Lester <[email protected]>: > > On Mon, Aug 5, 2013 at 10:45 PM, Jason Dusek <[email protected]> > wrote: > >> 2013/8/6 Dave Lester <[email protected]>: > >> > Awesome! Anyone want to give these a spin and help test? > >> > > >> > Jason: Do you plan to create similar packages for future Mesos > releases? > >> > The 0.12.1 release is close to being confirmed, and it would be great > to > >> > share Debs and RPMs at the same time we announce it. > >> > >> We would like to work together with the Mesos team to find a way > >> to automate builds for all (or the last three?) tagged releases. > > > > > > That would be great. I'd love if there was a person or team to own the > issue > > of builds for past, present, and future releases. Are you volunteering to > > help with all of those, or just previous releases? It may be easiest to > > track this via an Apache JIRA issue at > > https://issues.apache.org/jira/secure/Dashboard.jspa > > My goal at present is to provide some scripting tools so that > people can build the Mesos master repo and their own internal > repos. It will be a little while before I could commit to > ensuring timely (within an hour, for example) builds of the main > repo across many distros. And maybe some of this gets pushed in > to public build services like: > > https://build.opensuse.org/ > https://launchpad.net/ > > >> Some understanding of project policy (e.g., meaning of > >> 0.<something>.x) would help to guide the fancy Git scripting > >> needed for this. > > > > Is your question about the process by which releases are tagged, or > what's > > included in different releases? > > What I would like is a way to automatically discover new release > branches for building. For example, imagine a policy like this: > > * New release candidates have semantic version branch names with > an 'x' in them, like: > > 0.12.x > > * Released versions are tags in these branches, with no 'x', > only numbers. > > A script can then follow these steps: > > * List out all the branches that match > > /[0-9]+[.][0-9]+[.]x/ > > and sort them by semantic version. Pick the highest three. > > * For each such branch, list tags matching > > /[0-9]+[.][0-9]+[.][0-9]+/ > > and pick the highest two. > > * Build the tags selected above, assigning them the version they > are given, and build HEAD of each branch selected above, > assigning it a version with the 'x' replaced by '9999' and > adding a Git commit hash, like this: > > 0.12.9999~0c3fa21 > > * Upload all these builds. > > The important point about this is to have an automatic way to > build and package a few, relevant things and assign them a > meaningful version number. We can use git tags (which point to a > single commit) and branches (which point to a line of > development) to guide the automated build process. > > -- > Jason Dusek > pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B >
