[Edbrowse-dev] 3.5.3

[Edbrowse-dev] 3.5.3

[Karl Dahlke]

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.

Karl Dahlke

Re: [Edbrowse-dev] 3.5.3

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Edbrowse-dev] 3.5.3

[Chris Brannon]

Karl Dahlke <eklhad@comcast.net> writes:

> When should we mark the next version?

I'd say let's do it soon.  I've found a new bug with the html parser
though.  It's segfaulting on some input, and I'm trying to track it
down.  It's a regression, since 3.5.2 doesn't crash.
But maybe when we get that sorted out, 3.5.3 should be released.

-- Chris

Re: [Edbrowse-dev] 3.5.3

[Chris Brannon]

Adam Thompson <arthompson1990@gmail.com> writes:

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

I've been a distro packager for many years.  If distros want to make
experimental packages, then there are various ways to do that, and it all
depends on the distro's package building machinery and policies.
It can also be kind of frustrating.
Using something like 3.5.3.git as a version string in a
distro package manager is probably not the best approach, either, since
the code in git is a moving target.  So my instincts as a distro
packager tell me to let the distros worry about how to package
experimental code, since policies and machinery aren't standard.

-- Chris

[Edbrowse-dev] 3.5.3

[Karl Dahlke]

If you can wait another day or so, I should be receiving the Russian messages,
which would be nice to put in and definitely won't break anything.

Karl Dahlke

Re: [Edbrowse-dev] 3.5.3

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 284 bytes --]

On Mon, Feb 09, 2015 at 06:07:43AM -0800, Chris Brannon wrote:
> Ok, so is everyone in agreement that it's release time?  I think
> everything that has been mentioned has been resolved, so if I don't
> hear anything, I'll cut 3.5.3 within the next 12 hours or so.

Yeah, sounds good.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[Edbrowse-dev] 3.5.3

[Chris Brannon]

Ok, so is everyone in agreement that it's release time?  I think
everything that has been mentioned has been resolved, so if I don't
hear anything, I'll cut 3.5.3 within the next 12 hours or so.

-- Chris

Re: [Edbrowse-dev] 3.5.3

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 1843 bytes --]

On Sat, Feb 07, 2015 at 11:40:49AM -0500, Karl Dahlke wrote:
> > 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.
> 
> Well perhaps - but I'm trying to avoid git version complexity
> and branches and the like.
> The few intrepid folks who follow the latest often want the latest,
> even that last bug or feature that we just fixed,
> and they are sometimes helpful in finding more bugs, so we can fix them
> *before* any release or version cuts over.
> Recall when a user found a seg fault just last month and I fixed it,
> and didn't that happen a month before too?
> These are our beta testers, and I think they
> really do want the latest, and we want them to have the latest.
> It's a win win.
> Besides, our "unstable" snapshots aren't really that unstable.
> We are reasonably careful in what we push.

So if they want the latest they track head. This is very simple in git.
If they want the release branch (with bug fixes) they track release.
This enables us to do bug fix releases whilst getting on with major developments.
For example, currently we're debating whether to release 3.5.3,
but also talking about looking at tidy5 based html parsing and all the changes that implies.
If there's a bug in 3.5.3 which we don't find, but users do after the release,
we'll need a way to fix that, however we can't hold off the tidy5 (or other
parsing lib) changes
indefinitely (well we can but not if we want to make progress).
This hasn't been an issue before due to the incremental nature of changes,
however for less incremental changes this will become an issue fairly quickly I suspect.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[Edbrowse-dev] 3.5.3

[Karl Dahlke]

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

Well perhaps - but I'm trying to avoid git version complexity
and branches and the like.
The few intrepid folks who follow the latest often want the latest,
even that last bug or feature that we just fixed,
and they are sometimes helpful in finding more bugs, so we can fix them
*before* any release or version cuts over.
Recall when a user found a seg fault just last month and I fixed it,
and didn't that happen a month before too?
These are our beta testers, and I think they
really do want the latest, and we want them to have the latest.
It's a win win.
Besides, our "unstable" snapshots aren't really that unstable.
We are reasonably careful in what we push.

I think I'll defer to Chris on whether we should stamp version 3.5.3
now, or put some of his imap changes in first.

Karl Dahlke