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: Axb <axb.lists_at_nospam>
Date: Tue Sep 13 2011 - 21:59:21 GMT
To: "Kevin A. McGrail" <>

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

Indeed, I am +1 for not creating branches.

Years ago when there was much more dev work going on, I feel it made
sense. There was developers on steroids so freezes were necessary, but
as slow as new features are added now, I don't really see then need for

As atm, most users are interested in frequent rules /sa-updates,so IMO,
autopromoted rules should be try to be downward compatible, and if not,
be enclosed with if version tags.
Frequent SA releases may not as be as important for the average as long
as there are some rule updates available.
This is where I feel we should put emphasis.