First of all, during our standup meeting this morning, I got some feedback that my initial mail did not clearly communicate the fact that we intend to bump all platform versions to 1.0 when we release that version (so the whole release, all bundles and all packages will have that version number). That's the first thing we wanted to give people heads-up about!
The rest of this discussion is mainly about how to proceed after that. On Apr 26, 2012, at 10:21 AM, Bram de Kruijff wrote: > On Wed, Apr 25, 2012 at 7:38 PM, Marcel Offermans > <[email protected]> wrote: >> On Apr 25, 2012, at 19:03 PM, Bram de Kruijff wrote: >>> On Wed, Apr 25, 2012 at 5:20 PM, Marcel Offermans >>> <[email protected]> wrote: >>>> Do my answers help, or make it worse? ;) >>> >>> A bit of both :D That is to say... I think we agree on the big >>> picture. But my main question is "What will the tangible form of a >>> release be?" and you basically say "I don't care" which is fair enough >>> but not really helpful ;) >> >> The tangible form could be a zip/tar.gz that includes all the binary >> artifacts. Of course we can also publish the bundles in the Maven repository >> and/or in an OBR. >> >> All of these (binary releases) should be "for convenience" only. As an open >> source project, our main goal should be to produce a source release that >> people can build themselves. >> >> We've had some of these discussions in Apache ACE as well, and probably for >> the platform the most convenient way would be to release the whole source >> tree as one big release and then the most logical binary release would be >> one with all the artifacts as well. What I don't know is how Maven reacts >> when releasing some subprojects that have not changed. This probably needs >> some thought. > > Yes, I remember that discussion[0] and I still strongly disagree. I do > not want to make a big non functional tarball source or binary that > nobody will ever use. As I recall the only reason we did that for ACE > was to cut through the Apache red tape. We have multiple pretty > awesome delivery methods for source and binaries with git, maven and > provisioning that tie in nicely with development environment because > of the granularity. I do not believe any developer would wish for > anything more. Well, sooner or later we will have to make some kind of source release, either 1 zip or a whole bunch of them with instructions for people to build them. It's what Apache requires. After the ACE discussions, there has been a big discussion on the incubator mailing list. The bottom line was: 1) The only official Apache releases are source releases. 2) Source releases should only include sources and build scripts. 3) Build scripts are allowed to pull in binary dependencies, but if you really want to be nice, you should allow people to compile those from source as well (there was consensus that this, most of the time, is impractical). Apart from source releases, projects are allowed to make binary releases based on the sources, but those are seen as "nice to have" and they do not need voting on (because, what are you voting on anyway, since you cannot see what's in a binary release). I admit that this is a different discussion than how to version our artifacts, which is why I initially focussed on just the "nice to have" binary releases. > I guess I'm more thinking about the development (eg, maven > dependencies) and/or provisioning use cases. What do we give people to > tell them > "Hey look here is release x.y". Right now it's an email referencing > the repository and, as all artifact have the same version, it's easy > to find out where they are. Following, your example that will get > harder because of the independent version and so I'm wondering about a > solution. Why is is harder if all these artifacts are either in a single zip, or in a single folder? That groups them as well. And what's the alternative? Giving everything the same version? That makes very little sense to me because it means you're effectively constantly doing "big bang releases" and force people to recompile all their bundles (even if nothing has changed). > Anyway, getting back on topic, I was just wondering if strict semantic > versioning will work at the release level. It could bounce from 1.0 to > 2.0 (or even 3.0) just because there are some (non functional but > package) changes in a peripheral bundle that nobody uses. I guess > we'll see :) I think that if we're serious about being modular, we will have to make it work, but I'm curious what others think. Greetings, Marcel _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
