ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ant elder <antel...@apache.org>
Subject Re: Next release
Date Thu, 24 Nov 2011 20:33:31 GMT
On Thu, Nov 24, 2011 at 3:50 PM, Karl Pauls <karlpauls@gmail.com> wrote:
> On Thu, Nov 24, 2011 at 4:34 PM, ant elder <antelder@apache.org> wrote:
>> On Thu, Nov 24, 2011 at 3:25 PM, Karl Pauls <karlpauls@gmail.com> wrote:
>>> On Thu, Nov 24, 2011 at 3:48 PM, ant elder <antelder@apache.org> wrote:
>>>> On Thu, Nov 24, 2011 at 1:51 PM, Bram de Kruijff <bdekruijff@gmail.com>
wrote:
>>>>> On Thu, Nov 24, 2011 at 2:33 PM, ant elder <antelder@apache.org>
wrote:
>>>>>> On Thu, Nov 24, 2011 at 1:14 PM, Bram de Kruijff <bdekruijff@gmail.com>
wrote:
>>>>>>> On Thu, Nov 24, 2011 at 10:11 AM, ant elder <ant.elder@gmail.com>
wrote:
>>>>>>>> On Wed, Nov 23, 2011 at 8:14 PM, Karl Pauls <karlpauls@gmail.com>
wrote:
>>>>>>>>> On Wed, Nov 23, 2011 at 8:39 PM, Marcel Offermans
>>>>>>>>> <marcel.offermans@luminis.nl> wrote:
>>>>>>>>>> +1, I think providing such a script is a good way
to do it, it makes checking and building the individual components a lot easier whilst still
maintaining the flexibility of being able to release any subset of artifacts. I also agree
that we should correct the oversight of not shipping the pom.xml file as part of the source
distribution for future releases.
>>>>>>>>>
>>>>>>>>> Yeah, again, that is just a configuration we have to
set so that it
>>>>>>>>> not only generates the -sources.jar but also the -project.{zip,tar.gz}
>>>>>>>>> just like we do at felix. Without that (and there I totally
agree with
>>>>>>>>> ant and sebb on this one), it sucks rocks as you have
to massage the
>>>>>>>>> stuff quite a bit to get it to work and don't even have
the tests,
>>>>>>>>> etc. :-(.
>>>>>>>>>
>>>>>>>>> I think having the -projects plus the two scripts are
a good way to go
>>>>>>>>> (technically, its close to releasing the reactor pom
- which would be
>>>>>>>>> even easier -  but this way, we don't have to tag the
trunk).
>>>>>>>>
>>>>>>>> If having the reactor pom would be even easier then why not
do that?
>>>>>>>
>>>>>>> It's not that simple, cause the reactor does not know about versions.
>>>>>>> You could just zip the entire subversion, but this is not how
these
>>>>>>> projects our structured as each module in principle has it's
own
>>>>>>> life-cycle. For the same reason that tagging the entire trunk
does not
>>>>>>> make sense it would not make sense to release the infrastructural
pom.
>>>>>>> True, ACE still uses a global version, but just look at Apache
Felix
>>>>>>> and Sling and you'll know what I mean. IMHO, and I'm not an Apache
>>>>>>> person, the whole idea of having 1 release(version) is kind of
>>>>>>> artificial and antiquated. I can see why you need something like
that
>>>>>>> as a promotion criteria for incubator, but at the same time you
need
>>>>>>> to understand how these projects are structured and accept the
fact
>>>>>>> that there is not one version to rule them all.
>>>>>>>
>>>>>>>> This isn't just about making it possible for reviewers to
easily build
>>>>>>>> the release when voting its about having a source release
that you can
>>>>>>>> actually use to do development on the code. If you don't
release the
>>>>>>>> recator pom then for example how do you set up the source
in a IDE -
>>>>>>>> you'd have to manually go into each artifact any type something
like
>>>>>>>> mvn eclipse:eclipse, and even then that would give isolated
eclipse
>>>>>>>> projects so IDE refactoring wouldn't go across the projects
and IDE
>>>>>>>> changes in one project wouldn't be picked up until after
a maven build
>>>>>>>> was done and the projects refreshed, so really not a very
practical
>>>>>>>> approach.
>>>>>>>
>>>>>>> I don't think this is a valid argument. This is how Maven releases
>>>>>>> work and it provides great support for developer that work against
a
>>>>>>> released artifact. I declare a dependency to ace-something version
>>>>>>> x.y, my IDE dowloads the jar, the javadoc, the sources and I'm
happy.
>>>>>>> There is no good support for setting up a full ace development
>>>>>>> environment from the Maven repository, because that's not how
it
>>>>>>> intended to work. You use SCM to checkout project sources that
you
>>>>>>> want to develop on, import them into your IDE and make all the
magic
>>>>>>> work. You can't blame ACE for the fact that standard tools don't
>>>>>>> support a use-case that nobody actually needs... I think the
principle
>>>>>>> thing here is that, even if the subversion dies in a nuclear
attack,
>>>>>>> you could do it from these release artifacts.
>>>>>>>
>>>>>>
>>>>>> So i think what you're saying is that a full source release isn't
>>>>>> needed because there is an SVN tag for the release which has
>>>>>> everything you need if you want to do ACE development. Is that what
>>>>>> you mean?
>>>>>
>>>>> Not exactly what I was trying to say :)
>>>>>
>>>>> There is (and should be) a full source release for all release
>>>>> artifacts (for that particular version) based on the standard Maven
>>>>> -sources and related artifacts in the release repository. Together
>>>>> these contain all information needed to be able to setup development
>>>>> in any IDE and yes it will require some manual labor or a shell script
>>>>> or whatever.
>>>>>
>>>>> But IMHO you cant attack that with a ease-of-use argument cause nobody
>>>>> (outside this particular audit case) will ever do it like that in real
>>>>> world development. If so there would be support for it already and if
>>>>> Apache still thinks it should be supported by all means let's start a
>>>>> mavenrepository2myIDE project. I personally think it's a bad idea
>>>>> though, because you still will end up with a filesystem layout mapping
>>>>> to different tags/version. Again, look at Apache Felix or Apache Sling
>>>>> and try to imagine how a full source release for these types of
>>>>> project would look like when mapped to SCM and then think of the
>>>>> usefulness...
>>>>>
>>>>
>>>> Apache Sling does do exactly whats been asked for - go to
>>>> http://sling.apache.org/site/downloads.cgi and see the "Sling Source
>>>> Package".
>>>
>>> Not really. As we mentioned several times, sling follows a mixed
>>> approach. Modules are released independently and sometimes a big bang
>>> release with all bundles is created. For example, the "Sling Source
>>> Package" in version 6 contains org.apache.sling.scripting.jsp in
>>> version 2.0.14 but the latest released version of that one is 2.0.18.
>>> Didn't see a combined source release for that one ...
>>>
>>> At sling, we follow what we do at felix with the exception that we
>>> sometimes do a big bang release which contains everything.
>>>
>>
>> Right and that sounds totally fine. If theres a release of just sling
>> scripting 2.0.18 then just its source is released -
>> http://comments.gmane.org/gmane.comp.apache.sling.devel/22989 - and
>> when the big bang releases are done you get all the source. The ACE
>> 0.8.0 release was a big bang type release and from previous comments
>> it sounds like those will happen for example 1.0.
>
> Well, no. It looks like one but that is basically just because we did
> need to get all the components out. As I mentioned earlier, we (and
> that is true for sling as well as especially felix) batch up several
> components in one vote if it makes sense but that doesn't mean we will
> always release them together. Where do you want to draw the line? If
> we release two components, three, 15? When do we have to provide a
> combined source v.s. its fine to have individual sources? Unless your
> point is really that it can be only one component per vote then. In
> that case, I do you a release of a single component and that's it then
> (or if required, we would need to have, like, 50 different votes -
> which doesn't make sense to me).
>

The reason 50 different votes is impractical is because of what a pain
that would be to have to vote on all the separate votes - its so much
easier to just have them all in one vote email and vote with the
single +1 right? But thats only significantly easier if you're not
actually bothering to build and review the individual artifacts.

Where do you draw the line - 1, 2, 3, 15 or 50 per vote? A lot of
people would say 1 per vote, perhaps 2 or 3 is also ok, but if you
have 50 or 60 then there must be the expectation that no one is
actually going to be bothering to build and test them.

There are two issues here about ASF policy: one is if its required to
have a source release that is suitable for what has been described in
this thread as "full development", and the other is if when voting +1
on a release you should have verify that the source artifacts are
good. What i think people here are suggesting is that you don't need a
source release for "full development" as anyone wanting to do that
will get the source from SVN, and that its fine to have 50 or 60
artifacts in a single vote because you'll do things like have a script
to help building them.

I accept the documented ASF policy is not totally clear about this,
the release FAQ (http://www.apache.org/dev/release.html) i think
implies it and the two emails from Roy
http://apache.markmail.org/message/3odlybipss4wnczl and
http://apache.markmail.org/message/njray5dbazwcdcts are quite clear
about what he thinks, but he doesn't make policy by himself. So if you
really really don't want to change then just try to graduate and see
what happens, the worst that can happen is you'll be sent back to
change. Be clear thats what you're doing in the graduation vote on
general@ and then if the graduation succeeds this will have set the
precedent that clarifies things for everyone else in the future.

   ...ant

Mime
View raw message