> May I suggest a sligtly different approach ?
> It goes as follows :
> - declare a feature/string/deep freeze at the appropriate time for the
trunk
> [IIRC feature freeze was about two weeks ago]
> - for every (pre-)release just do a tag
> - at least until release candidates all bugfixes go directly to the trunk
> (if some new development really must be done during a freeze it can
> easily go into a specific branch and be merged after the thawing HEAD.
> Like it was e.g. done for the Gtk2 port ...)
That's what I did for 0.93, and I seem to remember you complaining about
why I did it that way rather than having a release branch.
Nope, at least not as far as I remeber, but it may be a matter of from
where one looks at it. As noted above, I think I've also done so in the
beginning of Gtk2 porting, where noone else was interested ...
But with 0.93 you *as the maintainer* declared official development should
take place on the created branch. Which gave us a bunch of bugs in bugzilla
which IMO were completely superfluous. [Just too much overhead for some
temporary expected breakage. Also wasn't there quite some highly
experimental stuff?].
Anyway the point I was trying to make is :
IMO a project with so few active developers should try to not split/loose
them over too many parallel branches. Also I would appreciate a little
warnig on dia-list if a feature is going to seriously break HEAD or maybe
even some notes on why a specific change should be done (or at least trace
in the ChangeLog)
"xpm->png, namespace fix, first rotation bits."
If there really needs to be a transition from xmp to png, please keep
*.shape, *.png _and_ Makefile.am in sync with your change.
Also *please* add png as binary - otherwise they'll not be arriving as
valid png on the windoze site. To fix it afterwards use 'cvs admin -kb
*.png' as mentioned in the ChangeLog (Now that *was* complaining ;)
Hans
-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it. -- Dilbert