|Main Archive Page > Month Archives > spamassassin-dev archives|
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, email@example.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. 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
>>> 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
> 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