spamassassin-dev September 2011 archive
Main Archive Page > Month Archives  > spamassassin-dev archives
spamassassin-dev: Re: September 30th release candidate Re: [Bug

Re: September 30th release candidate Re: [Bug 6658] Version 3.2.5 looks like it would be reasonable to install according to web site

From: Daryl C. W. O'Shea <spamassassin_at_nospam>
Date: Tue Sep 13 2011 - 23:28:30 GMT
To: dev@spamassassin.apache.org

On 13/09/2011 5:35 PM, Kevin A. McGrail wrote:
> On 9/13/2011 4:29 PM, Axb wrote:
>> On 2011-09-13 22:23, darxus@chaosreigns.com wrote:
>>
>>> We waste so much time backporting to the last branch. And trunk has been
>>> incredibly stable. I hate to see releases that aren't taken from trunk,
>>> seems like a waste of time and effort.

I don't think there's really a lot of effort to the backport. The
effort is going into the peer review that promotes the quality releases
that Apache is known for.

>> for once I agree with Darxus :)
>> There are a few usefull additions/fixes in 3.4 trunk which won't ever
>> get backported and it would be a pity to have to wait

Why not back port the few features/fixes?

>> +1
> +1. You two have convinced me that 3.3 can be abandoned and we release
> 3.4.0 out of trunk but I would want to see something that makes this
> major. That might be the ipv6 support for sa-update natively or
> something else completely. And it could delay it but these release date
> will hopefully get a fire under people.

If there are no (or few) major changes, why not do the backports. They
should be trivial. Has the branch really drifted that far out of sync
with trunk?

>>> http://wiki.apache.org/spamassassin/DevelopmentMode
>>> What that actually *says* is entirely compatible with not branching.
>>> It says trunk is *usually* commit-then-review, but temporarily switches
>>> to review-then-commit shortly before release.
>>>
>>> It looks like the method doesn't come down as a rule from Apache, so we
>>> could just say, since we're so damn good at keeping trunk stable,
>>> we'll do
>>> all our releases from trunk, and keep it commit-then-review.
>>
>> I'd +1 to cut a "beta1" out of trunk.
> My opinion is to wait on beta and go through bugzilla to make a list of
> bugs to get finalized so we have a list of "goals" for the 3.4.X
> release. Then people can start the commit frenzy.

The last thing I want to see is a C-T-R commit frenzy shortly before a
release.

> Alex, what are your thoughts on NOT creating a 3.4 branch and continuing
> with trunk for development? You seem to be pro the concept above and it
> makes sense that if we switch to rtc on trunk say 1 week or so before a
> release date as defined in the ReleaseGoals, everyone is happy.

I'm quite uncomfortable with that myself, however I haven't written a
lot of code for SA in the past couple of years myself. I do think
efforts should be placed on regular review of patches against stable
branches instead.

Daryl