[wp-hackers] On Subversion and 2.5.x-alpha not being in Trunk

Dougal Campbell dougal at gunters.org
Fri May 16 13:41:05 GMT 2008


I think that the branch is already doing what you want. I think the 
confusion here is that in a release branch, 'alpha' doesn't necessarily 
refer to the stability of the code, as it does in trunk. In trunk, the 
'alpha', 'beta', and 'RC' designations have their traditional meanings 
that we normally think of in development. But in a branch the WP 
tradition has mainly been to stick to 'safe' changes. So you can think 
of the 'alpha', 'beta', and 'RC' designations more of a "how soon will 
it become a bugfix release" sort of thing.

Here's how I would describe things, as I see it, based on what we've 
seen since the original switch from cvs to svn, and the later commitment 
to a release schedule:

trunk: Active experimental development for a future 'major' release. 
Expect breakage. alpha -> beta -> RC -> Release (copied to tags/X.Y and 
branches/X.Y) -> alpha++

tags/X.Y[.Z]: The official release snapshots. Fixed in time, never updated.

branches/X.Y: Active bugfix work, and possibly minor new features occurs 
in the newest branch. No API breakage should occur here, unless 
absolutely necessary to fix a major bug. At various points, there may be 
new point releases created from here, by copying to tags/X.Y.Z

That's my opinion/observation, anyhow. I consider the current branch to 
be 'stable', regardless of any alpha/beta designation. One of the 
official commit people can feel free to correct me if I'm speaking out 
of turn about the safety factor in the latest branch.

Now, as to whether there should be some sort of universal svn 'stable' 
pointer that always points to the latest-and-greatest bugfix branch...? 
I don't know. I can see how it could be useful for some people, but I 
think that upgrading between major releases should be a conscious step. 
Automating bugfix updates within a branch is fine. But doing an svn 
switch to a new release every few months isn't that big of a version. 
And it *can* be scripted, with just a little bit of work.

-- 
Dougal Campbell <dougal at gunters.org>
http://dougal.gunters.org/


John Blackbourn wrote:
> On Fri, May 16, 2008 at 1:33 PM, DD32 <wordpress at dd32.id.au> wrote:
>   
>> Looking back over the commit logs, /branches/ has allways been latest code
>> for a set branch, its never been static between builds, So i'm not sure
>> where the original suggestion that /branches/2.3/ or /branches/2.2/ were
>> constantly stable.
>>
>>     
>
> I work with several other projects that use Subversion and I think my
> mind is confusing them. I honestly thought /branches/xx always
> contained the latest stable release. I stand corrected!
>
> What I would ideally like is a place the latest stable release in a
> particular branch can be chcked out from, up to and including the
> current branch. This allows a blog to run on the latest stable
> release, but also allows you control in that a blog will stay on a
> particular branch until such time you want to switch it to a brand new
> branch release (in the case of 2.3 -> 2.5, it means you can
> update/test plugins and themes before doing so).
>
> It may go against the prinicple of tags but could 2.5.x trunk
> development be put into something like /tags/2.5-trunk and leave
> stable releases in /branches/2.5 ?
>
>   
>>> On Fri, May 16, 2008 at 1:07 PM, Dan Coulter <dan at dancoulter.com> wrote:
>>>       
>>>> On Wed, May 14, 2008 at 4:12 PM, Daniel Torreblanca
>>>> <regulatethis at gmail.com>
>>>> wrote:
>>>>
>>>>         
>>>>> If someone wants to avoid the hassle of typing in a url after "svn
>>>>> switch" I'd recommend a shell script that takes the version number as
>>>>> an argument... i.e. "upgrade_wp 2.x", which would then run "svn
>>>>> switch" with the appropriate URL.
>>>>>
>>>>>           
>>>> FWIW here's the bash script I was using on my last host:
>>>> http://pastebin.com/f5038a59c
>>>>
>>>> Just name the file something then append the version number as an
>>>> argument,
>>>> just like Daniel's example above.  You can add as many blog paths as you
>>>> like.  I'm not using that on my new host, but it's essentially the same
>>>> method, I'm just using a CLI PHP script that crabs a list of blogs to
>>>> upgrade from a database table.
>>>>
>>>> --
>>>> Dan Coulter
>>>> http://dancoulter.com/
>>>> http://phpflickr.com/
>>>> http://blogsforbands.com/
>>>>
>>>> Hey, I got nothing to do today but smile
>>>> -Simon and Garfunkel
>>>> _______________________________________________
>>>> wp-hackers mailing list
>>>> wp-hackers at lists.automattic.com
>>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>>>
>>>>         
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>>
>>>       
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>>     
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>   



More information about the wp-hackers mailing list