On Fri, Feb 06, 2015 at 05:48:19PM -0500, Karl Dahlke wrote:
> Ok I pushed a change so version is 3.5.3.git.
> Chris, when the time is right, update this to 3.5.3,
> mark that version in git, and then update to 3.5.4.git.
> But when should that be?
> When should we mark the next version?
> We've made a lot of changes, good changes, since 3.5.2.
> I've documented these in the CHANGES file,
> please check and make sure I haven't missed anything.
> Edbrowse works at least as well as before, and in many cases better,
> so should we soon cut a new version 3.5.3,
> or should we wait a bit and fold in the initial imap access
> that Chris and I have started working on?
> I would think no later than the imap push, we should mark the next version,
> because some of the next changes, like Adam looking into tidy5
> to parse html, are pretty substantial and systemic.

I'd say to go for the new version sooner rather than later.
Additionally, if we're going for 3.5.3.git I'd propose 3.5.3.release (or some
such) as a release version string. This is for a number of reasons,
not least that it'll make version sorting (and version dependant package
managers) behave correctly (git sorts before release in sorting)
whereas 3.5.3 would probably sort *before* 3.5.3.git.
This isn't a problem at the moment, but if we start publishing experimental
pre-compiled packages then it will be (incidentally I'd quite like to do
something like this at some stage if we don't already).
I've actually seen a case (can't remember which project exactly)
where package names ended up diverging from published version strings because of version sorting
reasons and would rather this didn't happen to Edbrowse.
It may also be interesting to think about having a head branch for development
and a release branch for releases since this'd allow people to follow releases
via git pull without having to worry about getting the latest unstable developments.
It'd also enable us to work on new features and cut a new release at the same time.

Cheers,
Adam.