cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: [VOTE] release 3.0.1
Date Mon, 16 Aug 2010 19:18:41 GMT
fixing for both 3.0 and 3.1 is the same amount of work as just fixing  
it for 3.1...

2.0... I hope we won't be having any more releases of that (and that's  
Ant based!!)

Andrus


On Aug 16, 2010, at 10:14 PM, Mike Kienenberger wrote:

> So what do we need to do?
>
> Fix it for this point release?   Make an exception for old point
> releases, and only fix it for 3.1?
>
> Fix our latest point releases for each currently maintained branch?
>
> My opinion is that we should fix all of the latest point releases, but
> I personally won't be able to do the work -- as I mentioned a couple
> months back, I'm in the middle of a go-live deployment of a three-year
> project for the next month or two, and I'm maven-ignorant.
>
> Second best would be to fix the 3.x branches.
>
> Third best would be to fix only 3.1.
>
> On Mon, Aug 16, 2010 at 3:04 PM, Andrus Adamchik <andrus@objectstyle.org 
> > wrote:
>> So again, I am convinced by your argument and the history trail of  
>> reasoning
>> behind it. Just feels that the solution that we might use (and that  
>> others
>> are using) and the desired ideal are pretty far apart from each  
>> other.
>>
>> Andrus
>>
>>
>> On Aug 16, 2010, at 9:43 PM, Andrus Adamchik wrote:
>>
>>> Yeah I vaguely remember this discussion -
>>> http://markmail.org/thread/njray5dbazwcdcts and I have to agree  
>>> with Roy's
>>> logic, which convinces me better than a mention of "policy" :-)
>>>
>>> Ok, so say we have a Maven build system that exports buildable  
>>> source with
>>> poms... which, considering the reliance on a public Maven repo for
>>> dependencies may not be that "buildable" 6 months from now :-/ Even
>>> open-source Apache-licensed (but not ASF-managed) packages may  
>>> disappear.
>>> How far can we go with that? (a good experiment would be to take a  
>>> year old
>>> existing ASF package and trying to build it, say Geronimo or  
>>> something of
>>> that level of complexity..)
>>>
>>> Andrus
>>>
>>>
>>> On Aug 16, 2010, at 9:28 PM, Mike Kienenberger wrote:
>>>>
>>>> It's one thing to state that it may not be a requirement to provide
>>>> buildable source, but it's quite a stretch to claim that we do  
>>>> provide
>>>> buildable source immediately after a message stating "It is
>>>> practically impossible to do that as the build system is ... well,
>>>> complex"  Taken to extremes, you could say that a jar file full of
>>>> classes is buildable source, since, with the right tools, you can
>>>> decompile the class files back to java code.
>>>>
>>>> But if you want to say that we're meeting the source build
>>>> requirement, consider this. It would mean that everyone voting +1  
>>>> on a
>>>> release has somehow thrown a home-grown build-system on top of the
>>>> source release and successfully built it.   Because that's the only
>>>> way an evaluator can be sure that the release has met the condition
>>>> and the release manager hasn't accidentally left out some required
>>>> piece of source.   We wouldn't say that we know that the release  
>>>> has a
>>>> valid checksum without checking it ourselves or that the release  
>>>> has a
>>>> valid signature without checking it ourselves.   Same goes for
>>>> building it.
>>>>
>>>>
>>>> On Mon, Aug 16, 2010 at 2:08 PM, Andrus Adamchik <andrus@objectstyle.org

>>>> >
>>>> wrote:
>>>>>
>>>>> On Aug 16, 2010, at 6:32 PM, Mike Kienenberger wrote:
>>>>>
>>>>>> Every ASF release must contain a source package, which must be
>>>>>> sufficient for a user to build and test the release provided  
>>>>>> they have
>>>>>> access to the appropriate platform and tools. The source  
>>>>>> package must
>>>>>> be cryptographically signed by the Release Manager with a  
>>>>>> detached
>>>>>> signature; and that package together with its signature must be 

>>>>>> tested
>>>>>> prior to voting +1 for release. Folks who vote +1 for release may
>>>>>> offer their own cryptographic signature to be concatenated with 

>>>>>> the
>>>>>> detached signature file (at the Release Manager's discretion)  
>>>>>> prior to
>>>>>> release.
>>>>>
>>>>> Actually, re-reading the above and it doesn't state a need of a  
>>>>> working
>>>>> pom.xml or build.xml, just the source that is matching the  
>>>>> binaries. In
>>>>> this
>>>>> respect we don't violate this. We do not provide a buildfile,  
>>>>> but a Java
>>>>> developer will be able to build the source regardless (e.g. by  
>>>>> writing
>>>>> build.xml himself, or importing sources in Eclipse).
>>>>>
>>>>> Andrus
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Aug 16, 2010 at 2:08 PM, Andrus Adamchik <andrus@objectstyle.org

>>>> >
>>>> wrote:
>>>>>
>>>>> On Aug 16, 2010, at 6:32 PM, Mike Kienenberger wrote:
>>>>>
>>>>>> Every ASF release must contain a source package, which must be
>>>>>> sufficient for a user to build and test the release provided  
>>>>>> they have
>>>>>> access to the appropriate platform and tools. The source  
>>>>>> package must
>>>>>> be cryptographically signed by the Release Manager with a  
>>>>>> detached
>>>>>> signature; and that package together with its signature must be 

>>>>>> tested
>>>>>> prior to voting +1 for release. Folks who vote +1 for release may
>>>>>> offer their own cryptographic signature to be concatenated with 

>>>>>> the
>>>>>> detached signature file (at the Release Manager's discretion)  
>>>>>> prior to
>>>>>> release.
>>>>>
>>>>> Actually, re-reading the above and it doesn't state a need of a  
>>>>> working
>>>>> pom.xml or build.xml, just the source that is matching the  
>>>>> binaries. In
>>>>> this
>>>>> respect we don't violate this. We do not provide a buildfile,  
>>>>> but a Java
>>>>> developer will be able to build the source regardless (e.g. by  
>>>>> writing
>>>>> build.xml himself, or importing sources in Eclipse).
>>>>>
>>>>> Andrus
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>


Mime
View raw message