wine-devel Digest, Vol 58, Issue 30

Maik Masling maik.masling at googlemail.com
Wed May 12 13:57:17 CDT 2010


Am 12.05.2010 19:00, schrieb wine-devel-request at winehq.org:
> Send wine-devel mailing list submissions to
> 	wine-devel at winehq.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://www.winehq.org/mailman/listinfo/wine-devel
> or, via email, send a message with subject or body 'help' to
> 	wine-devel-request at winehq.org
>
> You can reach the person managing the list at
> 	wine-devel-owner at winehq.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wine-devel digest..."
>
>
> Today's Topics:
>
>     1. Re: Release plans (Alexandre Julliard)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 12 May 2010 18:55:21 +0200
> From: Alexandre Julliard<julliard at winehq.org>
> Subject: Re: Release plans
> To: Scott Ritchie<scott at open-vote.org>
> Cc: wine-devel at winehq.org
> Message-ID:<87k4r93vra.fsf at wine.dyndns.org>
> Content-Type: text/plain; charset=us-ascii
>
> Scott Ritchie<scott at open-vote.org>  writes:
>
>    
>> On 05/09/2010 05:00 PM, Alexandre Julliard wrote:
>>      
>>> We definitely need a release changelog, yes.
>>>        
>> It seems to me what we really want is more than a changelog but a proper
>> release announcement.  I want a journalist who has hardly heard of Wine
>> to read the page and understand what we've done and why it's great.
>>      
> Sure, that's the press release, we should have one too, but it's a
> different thing. A changelog would be a detailed description of changes
> that matter from a user point of view. It would list for instance new
> builtin programs, new configuration options, new behaviors, new system
> dependencies, backwards compatibility concerns, etc.  You can't put that
> sort of things in the press release.
>
>    
That is a certain point. If the changelog would nounce namely working 
programs in series 1.2, than people would be more attracted into testing 
those but could be more dissappointed, because in fact more regressions 
to those "featured program"-list would pop up, especially after changes 
and with following 1.2.x.

To tell a non-programmer from a user-perspective point of view the 
advantages in featuring functionalities and supported application of the 
wine-project stable snapshots must not be like coding it again in 
foolish human language.

What I think the announcement really need to be is giving me/us a focus 
on the range of the advantages.
"What is the evolutionary point?"

I would be perfectly informed and proud to see it just like that:

Some few new famous massively used and working single/multiplayer games 
or programs that people heavily rely on. For example top 10 games + top 
10 applications  that work platinum with 1.2 plus an numeral overview of 
the status quo compared to 1.1 in platin,gold,silver,bronce,fixed bugs etc.

Compared:      1.0 / 1.1
Platin:                #  / #
Gold:                    "
Silver:                  "
Bronce:                "
Fixed Bugs:         "

What i really liked in earlier days was the animation with the 
gold,silver,bronce-bars, because that would easily visualise those process.

Wow, user thinks "How comes?" and we give him a additional sum-up of the 
changelogs main-points from all 1.1.* announcements plus the standard 
"additional/other/various bugfixes/improvements"-sentences that are 
regularly in part of the announcements.

I see no problem in just announcing it within WWN.
We could also just put the techie point inside of WWN and refer to it in 
the press release for a more detailed technical overvie of the advantages.







More information about the wine-devel mailing list