Back again
Matt Chaput
Well, at work we finally shipped the new version that's been taking so much of my time. In the meanwhile, Whoosh issues have piled up. I'll try to deal with them but I think at least some of them are fixed in the mainline.
Unfortunately I ran into a bit of a mess trying out some new features and a new on-disk format, and I might have to throw away or rebase some of that and try to get a new usable release out.
The big problem with the state of the mainline is that I've been experimenting without regard to backwards compatibility, planning to work it out later (in other words, being lazy).
The easiest way forward would be to break compatibility with old indexes and require a re-index. Not sure how big an issue it would be... I hoped not to do that again.
In the next week I'll try to deal with the issues in the bug list and figure out the best way to shape up a release. Any feedback is appreciated.
Thanks,
Matt
Roger Binns
Hash: SHA1
On 04/03/12 19:43, Matt Chaput wrote:
> The easiest way forward would be to break compatibility with old
> indexes and require a re-index. Not sure how big an issue it would
> be...
Doesn't affect me. I always do a complete reindex on application start
anyway. The reason is that the state with respect to the master database
is not known - eg the app could have been stopped while some more content
was added or removed. Or the master database could have been restored
from a backup. Consequently the only way to ensure that whoosh and the
database are consistent is the reindex.
I'd suggest only having one format and calling it Whoosh version 3. Far
less code to test, less code to go wrong and less to maintain. The
existing version of Whoosh hasn't suddenly broken, so developers can
upgrade on a schedule that works for them.
Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk9UVy8ACgkQmOOfHg372QRojACgiSA3XOds+MzBrO+iPKt8rdZu
4kYAoIYegQpCgoTxZxO61XXf7ZEHzTYI
=etQJ
-----END PGP SIGNATURE-----
Thomas Waldmann
Some ideas about the repo:
Maybe it would make sense to have the default branch for ongoing (but rather "safe outcome", small changes) development.
Additionally, have a 2.3-maintenance branch for bugfixes of 2.3.x (and to create releases 2.3.x from that branch)
Same thing with 2.4-maintenance branch that could be created when 2.4.0 gets released (forked from the changeset tagged with 2.4.0).
If a bug in a release comes up, one would fix the bug in the maintenance branch (so it is in the next bugfix release) and merge it back into default branch (so it will also be in next major/feature release).
For really critical development with unsure outcome, you could use other named branches (not default).
You'ld merge them into default branch when you think they are good enough for default branch users.
Of course one needs to be very careful to always work on the right branch...
About cleaning up:
If you change repo history by stripping the repo and reapplying changesets differently, I think that might make forked repositories invalid.
Whether that is a real problem might depend on whether there are incoming changes from theses repos (or even pending pull requests).
About tracker issues:
I sometimes have a bit time to help, but would need some comments in the issue tracker to choose the right path.
I read quite some whoosh source meanwhile, but it's not always clear whether something really is a bug or how to solve it.
About new index format:
As moin2 is not released yet: no issue for us with rebuilding the index.
BUT: I am not sure about risk of breakage with the new index format (like new, serious bugs, regressions), so I would prefer bugfix releases of 2.3.x without that change. And a new feature release (2.4.0 or 3.0.0) with that change.