Hi, On Thu, Sep 20, 2012 at 6:45 PM, Joe Bowser <[email protected]> wrote: > I know, I'm just saying that this has the same effect as releasing the > components independently. I'm not convinced that this would reduce > overhead when it comes to releases.
OK, fair enough. > Also, how would this make us conform to the Apache requirements > better? Not strict requirements as such (the current release package is IMHO fine from a policy perspective), but rather a more pragmatic point of view that underlies the Apache policies. The release guide [1] speaks of releases being "in the form of the source materials needed to make changes to the software", which in practice means that it's a good idea for the structure of the release to be as close as possible to the structure of the source in the version control system. The purpose of cutting a source release is not to satisfy an abstract policy but rather to produce something that downstream developers can easily use and modify to best match their needs. When looking at the current 2.1.0 release candidate my first impression is that there's no build script and the only instructions on how to build this thing is to "change directories to the platform that you wish to build for and read the README file." And to get to those platform sources I first need to unpack them to a separate directory. I might be wrong, but it seems to me that most people would rather simply start from a tag of a relevant platfrom repository instead of building the release candidate. If that assumption is correct, then I think it would be a good idea for the release structure to better match the expected access patterns. The main point I'm trying to address here is the grumbling I see about the whole release process and its inefficiency. If the outcome of the release process isn't something that's useful, then we're doing something wrong and should fix that. If the process itself is too complicated or otherwise takes too long, we should fix that too. I'd love to hear also other ideas on how that could be done. [1] http://www.apache.org/dev/release.html#what BR, Jukka Zitting
