maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <jvan...@sonatype.com>
Subject Re: Suggested change to site / release
Date Sun, 19 Jul 2009 13:07:38 GMT
Just getting back after being sick for a week.

On 10-Jul-09, at 7:18 PM, Brett Porter wrote:

> sorry, these changes should have been on a branch. I'll move that  
> across now so that trunk is still deployable. I'm heading out now  
> but I can respond to these issues later.
>

No biggie. I just think the notes being aggregated to be a good thing.  
Doesn't mean we can't do both if it's still convenient.

> On 11/07/2009, at 12:27 AM, Jason van Zyl wrote:
>
>>
>> On 10-Jul-09, at 1:48 AM, Brett Porter wrote:
>>
>>> Hi,
>>>
>>> I've committed some changes that I'd like reviewed to go forward  
>>> with which makes Maven releases easier.
>>>
>>> 1) see http://maven.apache.org/docs/2.0.11-RC1-SNAPSHOT/release-notes.html 
>>>  (may not be present yet due to proxying), and relevant commits in  
>>> that RC branch
>>>
>>> 2) see commits in site branch.
>>>
>>> The basic approach is this:
>>>
>>> * push all release notes into docs/$version/release-notes.html  
>>> instead of the consolidated older format and add a page to list  
>>> them in order
>>>
>>
>> So if someone wants to see the historical list of changes they will  
>> need to look at N documents? The consolidated format is good as the  
>> history of change is kept in one place which is what people looking  
>> to migrate want to see.
>>
>>> * move the release notes for all future versions of Maven into the  
>>> Maven tree itself. This means that you can create/edit them as  
>>> they are a snapshot without messing up the site, and publish them  
>>> automatically with the release.
>>>
>>
>> Again these changes span versions. I have no problem keeping these  
>> in SVN somewhere but chopping up the release notes into multiple  
>> documents makes it really hard to view the high level changes over  
>> time. If folks want to see exacting detail per version they can get  
>> this from JIRA. The release notes should be cohesive spanning  
>> multiple versions. They at least need to be in an aggregated form  
>> somewhere.
>>
>>> * set the release up to publish the above site and javadoc/xref at  
>>> release perform time (this is before the vote, but as it is  
>>> versioned it is not going to be live)
>>>
>>
>> If you mean coupling the publishing of site during the release then  
>> -1.
>>
>> The site publishing cannot be coupled to the actual release. The  
>> release of the binaries should not fail because of some  
>> aggregation, ordering or some other problem with the reporting/site  
>> system. Whoever is doing the release can do this in two steps. Some  
>> external system could orchestrate this but the actual release  
>> itself should not couple the site publishing the distribution of  
>> binaries.
>>
>>> * consolidate all version specification for the main site in  
>>> pom.xml, so only those properties need to be edited (I removed  
>>> 2.1.x, so we have the currentStableVersion - 2.2.0,  
>>> current20xVersion - 2.0.10, and a list of all releases for  
>>> generating the previous release notes, + corresponding dates for  
>>> the current releases)
>>>
>>> * remove use of symlink for "current" and instead filter those  
>>> properties into .htaccess
>>>
>>> This means that to do a release, assuming it works (which I'll  
>>> test with 2.0.11), it's only the release:prepare / perform cycle +  
>>> upload binaries to www.apache.org (to be automated) + site/pom.xml  
>>> edit and site-deploy.
>>>
>>> The downside of the separate site approach is that the release  
>>> notes drop the main navigation (but there is a "Documentation"  
>>> link back to the main site). I don't think this is a bad thing.
>>>
>>> Any objections to continuing this approach with Maven 2.2.x, and  
>>> perhaps making similar attempts on the plugins?
>>>
>>
>> As bad as the site is now people are accustomed at least to the  
>> structure. I really think you should think hard about wanting to  
>> flip all this around again. The problem on the site is the content,  
>> not the structure. There is actually far too much structure are far  
>> too little meaningful information. I honestly don't think this is  
>> the best use of anyone's time and the focus should be  
>> simplification and clarifying the existing content more then  
>> anything.
>>
>>> Cheers,
>>> Brett
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>> http://twitter.com/jvanzyl
>> http://twitter.com/SonatypeNexus
>> http://twitter.com/SonatypeM2E
>> ----------------------------------------------------------
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
http://twitter.com/jvanzyl
http://twitter.com/SonatypeNexus
http://twitter.com/SonatypeM2E
----------------------------------------------------------

First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.

   -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message