Hi all
the big question for me is how git archive will be used, does it just
solve (1) as mentioned by Jens? What about updating version tags within
source tree and creating a tarball of the tree for a release?
So users need to sh bootstrap.sh or just use CMake or any other specific
build system such as npm.
The other question is how CMake should accelerate the release procedure.
To you think we should have e.g. a package.json and package.json.in file
within the tree? One for preparing the release easily and the other for
people hacking directly on the git tree as most people do.
Quarterly releases would be very good so people can use latest tagged
release within their projects.
bets!
roger
Quoting Jens Geyer <jensge...@hotmail.com>:
Hi,
(1) If git archive solves the problems I'm for it. If EXTRA_DIST is
made obsolete by this step I'm even more for it.
(2) Time plan sounds feasible to me. A week more or less will not
harm anyone, so let's just do it.
(3) Regular schedule sounds great! Not sure about monthly, though.
My first reaction was, bimonthly or quarterly (= 3 months) is
probably enough and would be a great leap forward. On the other
hand, if we somehow could manage to get into a position where we are
able to do a release basically on the proverbial spur of the moment,
just by pushing a few buttons, then we can have whatever release
schedule makes sense vis-à-vis features implemented and bugs fixed.
We could even make it based on a milestone feature set, instead of a
fixed schedule. Not sure how close we can get to that goal and how
much effort it takes (and where it stops making sense), but that's
what I imagine.
Have fun,
JensG
-----Ursprüngliche Nachricht----- From: Jake Farrell
Sent: Friday, October 2, 2015 7:24 PM
To: dev@thrift.apache.org
Subject: [DISCUSS]: Source release artifact
In an effort to make releases easier to cut I would like to propose that we
move to using git archive with a .gitignore to exclude any files that we
feel should not be apart of the release. This will help cut down on time
spent tracking missed files in the EXTRA_DIST section and having to compare
the release dist versus whats in the repository.
My thought is that we work towards the cmake switch as follows:
0.9.4: end October - Switch to git archive
0.9.5: end November - Unify build/test env (Jenkins/Travis/etc all using
Docker)
1.0: end December - Switch to cmake
And what is everyone preference moving forward for release cadence, would
like to get on a more regular schedule. monthly, quarterly?
Thoughts?
-Jake
