You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2008/07/08 00:13:40 UTC
Internally self-consistent releases
Hi,
I'm working release planning, and I want to define how we actually
build Maven for a release.
For me it essentially boils down to:
Use the last bootstrap version of the build to produce the version of
Maven for the given release.
I think this lets us remain internally self-consistent, and avoids the
previous release problem. If we use the last stable version of Maven
we get into the problem of requiring all those versions if you really
wanted to start from scratch. I think this makes it self-contained and
will keep the Linux distro people happy because they can build
everything from source.
If no one has any objections I'm going to build this into the release
plan for 2.1 and codify it in Hudson.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Internally self-consistent releases
Posted by Jason van Zyl <ja...@maven.org>.
On 7-Jul-08, at 10:37 PM, Brett Porter wrote:
>
> On 08/07/2008, at 11:59 AM, Brian Fox wrote:
>
>> You mean bootstrap first, then use that build to run
>> release:prepare...?
>
> I would expect release:prepare to be run normally, but the bootstrap
> to be used in release:perform if this is the case.
>
Yes, with the previously built bootstrapped version.
>>> I'm working release planning, and I want to define how we actually
>>> build Maven for a release.
>>>
>>> For me it essentially boils down to:
>>>
>>> Use the last bootstrap version of the build to produce the version
>>> of Maven for the given release.
>
> I'm fine with that (I'm also fine with "use the last release and
> only the last release of Maven to produce the release").
>
>>>
>>>
>>> I think this lets us remain internally self-consistent, and avoids
>>> the previous release problem.
>
> What was the previous release problem?
>
I just want know that it's coming off the same machine with the same
pattern so that we have some control. There's been platform specific
things in the past. I don't know if there has ever been any problems
because one release was made with a particular version of maven. But
we will know from now on.
>>> If we use the last stable version of Maven we get into the problem
>>> of requiring all those versions if you really wanted to start from
>>> scratch. I think this makes it self-contained and will keep the
>>> Linux distro people happy because they can build everything from
>>> source.
>
> I'm not sure about that, since the bootstrap still downloads a
> number of binary dependencies, but they're easily substitutable and
> it's a start.
>
With the version map in properties the way I've now setup they could
if they wanted to. And John actually has code we used for some C stuff
to build the dependency from source first. Actually we should probably
share that with the Linux heads.
>>>
>>>
>>> If no one has any objections I'm going to build this into the
>>> release plan for 2.1 and codify it in Hudson.
>
> I'll respond to John's mail directly, but I think there's some
> issues with this.
>
Not sure what you mean, with building consistently with a bootstrapped
version?
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Internally self-consistent releases
Posted by Brett Porter <br...@apache.org>.
On 08/07/2008, at 11:59 AM, Brian Fox wrote:
> You mean bootstrap first, then use that build to run
> release:prepare...?
I would expect release:prepare to be run normally, but the bootstrap
to be used in release:perform if this is the case.
>> I'm working release planning, and I want to define how we actually
>> build Maven for a release.
>>
>> For me it essentially boils down to:
>>
>> Use the last bootstrap version of the build to produce the version
>> of Maven for the given release.
I'm fine with that (I'm also fine with "use the last release and only
the last release of Maven to produce the release").
>>
>>
>> I think this lets us remain internally self-consistent, and avoids
>> the previous release problem.
What was the previous release problem?
>> If we use the last stable version of Maven we get into the problem
>> of requiring all those versions if you really wanted to start from
>> scratch. I think this makes it self-contained and will keep the
>> Linux distro people happy because they can build everything from
>> source.
I'm not sure about that, since the bootstrap still downloads a number
of binary dependencies, but they're easily substitutable and it's a
start.
>>
>>
>> If no one has any objections I'm going to build this into the
>> release plan for 2.1 and codify it in Hudson.
I'll respond to John's mail directly, but I think there's some issues
with this.
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Internally self-consistent releases
Posted by Jason van Zyl <ja...@maven.org>.
It would have been the last good build from the bootstrap so
effectively that, yes.
On 7-Jul-08, at 9:59 PM, Brian Fox wrote:
> You mean bootstrap first, then use that build to run
> release:prepare...?
>
> --Brian
>
>
> On Jul 7, 2008, at 6:13 PM, Jason van Zyl <ja...@maven.org> wrote:
>
>> Hi,
>>
>> I'm working release planning, and I want to define how we actually
>> build Maven for a release.
>>
>> For me it essentially boils down to:
>>
>> Use the last bootstrap version of the build to produce the version
>> of Maven for the given release.
>>
>> I think this lets us remain internally self-consistent, and avoids
>> the previous release problem. If we use the last stable version of
>> Maven we get into the problem of requiring all those versions if
>> you really wanted to start from scratch. I think this makes it self-
>> contained and will keep the Linux distro people happy because they
>> can build everything from source.
>>
>> If no one has any objections I'm going to build this into the
>> release plan for 2.1 and codify it in Hudson.
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>> happiness is like a butterfly: the more you chase it, the more it
>> will
>> elude you, but if you turn your attention to other things, it will
>> come
>> and sit softly on your shoulder ...
>>
>> -- Thoreau
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
To do two things at once is to do neither.
-—Publilius Syrus, Roman slave, first century B.C.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Internally self-consistent releases
Posted by Brian Fox <br...@reply.infinity.nu>.
You mean bootstrap first, then use that build to run release:prepare...?
--Brian
On Jul 7, 2008, at 6:13 PM, Jason van Zyl <ja...@maven.org> wrote:
> Hi,
>
> I'm working release planning, and I want to define how we actually
> build Maven for a release.
>
> For me it essentially boils down to:
>
> Use the last bootstrap version of the build to produce the version
> of Maven for the given release.
>
> I think this lets us remain internally self-consistent, and avoids
> the previous release problem. If we use the last stable version of
> Maven we get into the problem of requiring all those versions if you
> really wanted to start from scratch. I think this makes it self-
> contained and will keep the Linux distro people happy because they
> can build everything from source.
>
> If no one has any objections I'm going to build this into the
> release plan for 2.1 and codify it in Hudson.
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will
> come
> and sit softly on your shoulder ...
>
> -- Thoreau
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org