> On Dec. 12, 2013, 4:10 p.m., Maxim Khutornenko wrote: > > build.gradle, line 34 > > <https://reviews.apache.org/r/16228/diff/1/?file=397060#file397060line34> > > > > Could you please describe what the publishing procedure is going to > > look now? How do we publish next version 0.0.13? > > Kevin Sweeney wrote: > Here we're skipping straight to 0.2.0 to get a consistent version number > between Java and Python components (which should be published together and > atomically). As for the publish step, it'll be as follows (but automated). > > 1. Create a branch "v0.2.0" off master and perform a single commit, > changing 0.2.0-SNAPSHOT or 0.2.0-dev to 0.2.0 everywhere. > 2. Run all the tests to make sure this isn't a bogus release. > 3. Create a tag "0.2.0" pointing to that commit, ideally signing that tag. > 4. Create artifacts - jars and sdists using pants and gradle. They will > have the newly-created version in their metadata. > 5. If everything looks good, this tag can now be pushed to origin and > downstream dependees can use it. > 6. Publish jars to Maven central and sdists to PyPI. > 7. Create a new commit on master changing "0.2.0-SNAPSHOT" and > "0.2.0-dev" to "0.2.1-SNAPSHOT" and "0.2.1-dev". > > Maxim Khutornenko wrote: > I am fine with steps 1-6. However, I think we should have more details > around versioning in step 7. How do we release a hotfix from the tagged > branch if needed? Would it be something like 0.2.0-hotfix#? I don't think > that would be a semver-compliant use of build metadata. I propose we bump the > minor version x.Y.z when merging back to master and reserve patch field > (x.y.Z) for the hotfixes. In your example that would be 0.3.0-SNAPSHOT/dev. > Thoughts?
Agreed, step 7 should increment MINOR instead of PATCH. - Kevin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/16228/#review30304 ----------------------------------------------------------- On Dec. 12, 2013, 4:05 p.m., Kevin Sweeney wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/16228/ > ----------------------------------------------------------- > > (Updated Dec. 12, 2013, 4:05 p.m.) > > > Review request for Aurora, Bill Farner, Brian Wickman, and Zameer Manji. > > > Bugs: AURORA-10 > https://issues.apache.org/jira/browse/AURORA-10 > > > Repository: aurora > > > Description > ------- > > Pin master to -SNAPSHOT and -dev versions. > > This ensures that we don't inadvertendly publish artifacts that aren't > the final tagged version. A future review will introduce tooling to > automatically and atomically increment these version numbers. > > > Diffs > ----- > > build.gradle c66afa8f9dba7f1e772c67aeb5316894f31036c9 > src/main/python/twitter/aurora/client/BUILD > a96a801042c2f3d523ee58645a077e47ce9eac38 > src/main/python/twitter/aurora/config/BUILD > 0462158357730865387d0ead001077f39bba6dcb > src/main/python/twitter/aurora/executor/BUILD > 02d34f0354e1452731353bd43e43eed9d034398a > src/main/python/twitter/thermos/BUILD > 7c5d760c863c2f56d6518a0fbb01aa361c0e6db2 > src/main/python/twitter/thermos/common/BUILD > 38de710368dfff46f1dae6df1b878e3d81eb28d3 > src/main/python/twitter/thermos/config/BUILD > 7b889d28d13126c4f003c87c7853a0e9ed4e82a5 > src/main/python/twitter/thermos/core/BUILD > 014b1f7fa3cc45661c194ae8256fe9767530c3b3 > src/main/python/twitter/thermos/monitoring/BUILD > 8601c4eae76aad380274076e7df088c1e8d33ba3 > src/main/python/twitter/thermos/observer/BUILD > 090d3ad33083d5ea51a34af29412134afddcc9e2 > src/main/thrift/com/twitter/aurora/gen/BUILD > a21f2fc796871ff74b1af4852ec298d75458d442 > src/main/thrift/com/twitter/thermos/BUILD > c224d8d5e87f05ea37ac8ecc4ba223228a32b8a5 > > Diff: https://reviews.apache.org/r/16228/diff/ > > > Testing > ------- > > > Thanks, > > Kevin Sweeney > >
