0.1.0
diem
There were a few minor changes since the rc release:
*cleaned up messages
*repacked the structs to save some memory
*removed the -g compiler flag (this should be stable, so debugging
symbols shouldn't be necessary)
With the stable release out, euclid is going to be in maintenance mode
for a few months, so there won't be any big changes for a while (I
might poke around with it now and then, but nothing big). This will
give me a chance to just use it and figure out what's next.
Feedback is still welcome, and I will be watching for new issue
reports and fixing bugs if they are found.
Cheers,
wmd
BKLive
for both svn and stable. I'm not sure how often you plan on making svn
changes, but having that option open is a benefit.
Good work!
BKL
BKLive
build? Is there a criteria for minor revisions (X.X.n where n is minor
rev)? For example svn v144 updates the error handler flag (-g) which I
am assuming you re-added for bug tracking(?), so would that or the fix
for whatever bug you're trying to check for meet the requirement for a
minor update? Have you thought about a release management policy (or
for that matter another developer to package new releases based on the
policy)?
If you don't have the time to update the build every time you fix one
or two changes and can come up with a list of priorities that warrant
a stable upgrade, then I could volunteer some of my own time to put
those packages together so you could focus instead on changes to
actual function/form (since my skills really limit themselves to
package maintenance and testing), and maybe release some of the burden
of package maintenance. If you need it, that is.
Again, awesome work! I use euclid all the time now, no bugs, only
cosmetic blunders (move some terminals around and your cursors will be
offset a lot (urxvt), and if you have skype maximized and hit the "un-
full-screen" button it'll make a small, untiled window (like
floating)) which don't bother me because you have to force it to do
this. Which is also why I'm not reporting these as errors lol
Let me know about the package maintenance thing!
BKL
William Diem
releases correspond to the n in X.X.n (micro releases).
I'm going to try to hold new features for minor releases, (m in
X.m.n). However, if I judge that a minor new feature poses little
chance to introduce new bugs and doesn't change the established
behavior of the minor release line, I might push that out with a micro
release (X.X.n).
So for the next few months I'm not planning to be pushing out any
minor releases, just micros. And these will be pushed out in a passive
way; when a bug is found and fixed there will be a new release. So
there is no schedule at the moment.
Right now for example, I've committed a bugfix for what I think was a
pretty minor bug (under certain debugging conditions, euclid would get
stuck in a loop of spawning xterms that were running another instance
of euclid: quite bad for usability when it bites, but I hadn't worried
about it too much because I could only produce it under specific
debugging conditions, and no one else had reported it). I'm also
waiting for some information from a tester who has experience a
problem with glibc aborting euclid at startup because of a bad free (I
really hope no one else has seen this). I'm hoping to get this last
one fixed and then roll 0.1.1 with both of them.
As far as svn v. stable pkgbuilds. I like having both, but whether
there is much point to keeping them separate (at the moment) depends.
I.e., I'm planning to restrict myself to bugfixes for a while, and I'm
planning to put out new releases for bugfixes, so the svn and the
current release should basically stay in sync. No guarantees though, I
might get ambitious and fork the svn to start developing new features,
in which case having people running from svn would be nice, but I
don't presently plan to. Of course when/if I decide to do another
spurt of heavy development with lots of new features having both of
them will be really nice.
WRT packaging. Thanks a lot for the offer, but the tarball isn't much
work for me. In fact it's almost automatic.
The packaging task that I haven't felt up to doing is making a .deb
and an rpm. I doubt you would want to tackle either of those, since
you are an Archer, but if you do (or anyone else does for that
matter), it would be great to have.
I think I hit all the points. Tell me if I forgot something.
Thanks for the work you've done on testing and maintaining the
pkgbuild. It's been a lot of help to me.
Best,
Will