Just to follow up - as i've progressed on putting together tooling for
building artifacts on a regular basis [1], splitting out the packaging
tooling seems like the most sane approach. In addition to the reasons
already mentioned w.r.t. tagging, it will be much easier to manage
isolation of the
I'm mostly indifferent to whether the packaging code lives in another
repo. Anyone else have an opinion?
-=Bill
On Tue, Jul 28, 2015 at 6:19 AM, Jake Farrell jfarr...@apache.org wrote:
Going back to the 0.9.0 example, if I checkout the 0.9.0 tag it will always
have a broken
+1
On Mon, Jul 27, 2015 at 3:40 PM, Bill Farner wfar...@apache.org wrote:
Hi folks,
An issue that we have not yet officially addressed is release management as
it pertains to binary artifacts we produce of Aurora. Today, when we cut a
release, say 0.9.0, we essentially take a snapshot of
Hi folks,
An issue that we have not yet officially addressed is release management as
it pertains to binary artifacts we produce of Aurora. Today, when we cut a
release, say 0.9.0, we essentially take a snapshot of (most of) our
repository as a basis for voting and eventual distribution.
An
In order to make this repeatable it might be good to split this off
entirely into its own aurora-packaging repo. If its still in the main repo
then when we create the release branch the packaging source will still be
in the new release branch, but the packaging code would not necessarily
line up
Wouldn't a separate repo make it even more difficult to associate build
script changes to source code changes?
-=Bill
On Mon, Jul 27, 2015 at 8:22 PM, Jake Farrell jfarr...@apache.org wrote:
In order to make this repeatable it might be good to split this off
entirely into its own
