Henrik K wrote on 19/12/22 5:43 am:
Mass check runs from trunk, there are no ties to any specific version, aside
from testing built rules.tar.gz with all 3.4 and 4.0 releases.
It seems like
1. Branching svn would not impact mass check, which will continue to run
from trunk
2. If we ever decide to move to git, we could if we wanted to stage the
process by keeping the rules and rulesrc directories in svn at first
with minimal change to build and mass-check scripts
3. We don't have a compelling reason to have to move to git, nor do we
have committers clamoring to move to git, nor do we have a total
consensus to move to git. We do have some committers who would like a
move to git. That leaves it in the realm of something to keep in mind
but not to go through the effort of implementing right now.
4. We don't need to branch until someone presents something big enough
to justify having separate 4.0.x and 4.1.x development branches. More
specifically, we would have to have something that we commit to trunk
that is not ready for an immediate release, and we would have to have a
reason to release a 4.0.x immediately without that partial code that was
committed to trunk. As Henrik pointed out, we can adopt some of the git
development philosophy of using a feature branch to develop a feature
and only committing to trunk when it is finished. It isn't the "svn way"
but it would work and would avoid problems like we had with large
changes like welcome/blocklist renaming.
5. We don't currently have any big plans for changes in SpamAssassin 4.1
now that the move to Unicode support is finally completed. If it turns
out that the future of SpamAssassin is in ongoing work om rules, the
masscheck process, and new plugins, I can see that there may never be a
reason to create separate major/minor version development branches.
6. That said, I'm certainly open to hear from anyone who does have any
proposal for future features and improvements.
Regards,
Sidney
