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: <darxus_at_nospam>
Date: Tue Sep 13 2011 - 20:23:49 GMT

On 09/13, Kevin A. McGrail wrote:
> re: 3.4.0RC. Hard to say if it's 3.3.X or a 3.4.X. We have the
> minor API change with one variable is about the only reason to call
> it 3.4 because that API change needs to wait for a major release.
> I'm not sure ANYTHING else classifies as a major change.
> I'd like to make a goal to get sa-update a lot cleaner and ipv6
> native release which I'm working on infrastructure for and call it
> 3.4.x.

Are you suggesting doing a release of what is now in trunk and calling it
3.3.3? That seems confusing, as far as managing branches. Would you
overwrite the existing 3.3 branch with it? I guess trunk is stable
enough, I don't have a good idea of the significance of changes, I
just like the idea of the major version staying the same meaning only
carefully selected backports of patches have been applied.

Or are you actually talking about doing another release of what's currently
in the 3.3 branch? That seems like a complete waste of time to me.

I'd be comfortable with releasing what's in trunk as 3.4.0 now and then
doing the next release in January as 3.5.0 with your IPv6 stuff.

> re: Release manager. We still have a cart before the horse issue on
> release manager due to the key signature. The number of people who
> can sign a release is dramatically too low. I might step up as the
> manager so I can document more of the process and so we have more
> hands making light work

Sounds fine. Documentation is nice.

> re: leaving 3.4 as trunk to me makes sense. We have nothing major
> enough in the works to justify otherwise EXCEPT our r-t-c rules for
> branches vs trunk. I could argue it either way which probably means
> I'd vote to maintain status quo (i.e. to move trunk to a branch and
> create a new trunk).

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.
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.

-- "It's a dangerous business, Frodo, going out your front door. You step into the Road, and if you don't keep your feet, there is no knowing where you might be swept off to." - Bilbo Baggins