On Saturday 22 May 2010 14:07:34 Konstantin Tokarev wrote:
That also break compatibility - the target should remain avogadro, as
it was int the release.
As you wish
Targets will be:
avogadrocore - non-gui-related
avogadrowidget - gui, plugin management
avogadro - everything
is it ok?
That would preserve compatibility. Also, in general you want to change the
target name to reflect the library name, rather than changing the output name.
It makes it much easier to relate the target to the compiled binary.
OUTPUT_NAME should only really be changed in situations where you have things
like avogadro and avogadro-app (both would naturally have the same target
name, but cannot).
I am not sure what you mean by early stage - Avogadro has been in
development for a number of years.
Surely, but it doesn’t mean it’s already perfect or used in hundreds
of projects. Later it would be harder to make changes.
You seem to miss my point that we have already put off freezing, 1.0 was a big
milestone. Whether it is hundreds or five, and remember chemistry is quite
niche, and unlikely to ever read the numbers you are expecting. It would be
great if it did though.
There are some almost obvious drawbacks in design (e.g., OpenGL and
Python are fastened with nails instead of more flexible solution,
read “Refactoring Ideas”). I think if they won’t get fixed and we’ll
keep everything “1.0-compatible”, they’ll stay for years
We already relaxed into breaking ABI for the next release. Never claimed that
things were perfect, and I was never sure we had Python down. A separate
target probably does make a lot of sense there. You don’t see Qt splitting
into hundreds of libraries for each widget, and you certainly don’t see them
moving public API between libraries in minor releases.
It would be great to have at least approximate statistics how many
people use Avogadro for development.
How do you expect to get those for any open source project? I am not sure I
can share the identities of everyone who has emailed me with questions about
developing Avogadro related code (I would have to check with them).
Given more time I have hundreds of ideas, many of which involve redesigning
our API. How about building a full scene graph for rendering, and using that
with point sprites for highly scalable OpenGL 2.0 rendering. I have some local
code where I have experimented with that.
Highly experimental changes should happen in branches, mature, and if they
look good land in master when they are ready. I purposefully kept some large
chunks of code out of our public API because they were not ready, and I didn’t
want to commit to supporting them.
If I split out rendering, and do it in another separate library, I will also
use a separate namespace, so that the old Avogadro rendering code would still
be valid. I would want to continue to support it until a 2.0. It sounds like
there is so much you feel must change, that you need to on a 2.0. If that is
the case, then perhaps working in a branch on a longer term vision is the
right thing to do there.
There are ways to continue innovating without constant refactoring and
tweaking. You make large changes in chunks, minimize disruption to users. If
you want to work on a 2.0 candidate, then why not try it. I just don’t think
we should release it as 1.2. If it is not backwards compatible in any real
way, then call it what it is. I was hoping to get at least one or two minor
releases out, but in all honesty with what I have learned and some time could
write an amazing 2.0 release.
I am not making this stuff up, these are commen expectations with release
numbers. It sounds like you want to rewrite and refactor large parts of
Avogadro, that would need to have a 2.0 label on it. If we want to abandon 1.y
line already, that is OK, but it should be stated. I can backport what we want
to 1.y and make some bug fix releases. Eigen is on their 3.0 effort already.
If we are going to have a 2.0, then may be everything gets re-examined, we
work on it. I will backport/improve 1.0 to keep our userbase happy. When 2.0
starts to settle, then we start to make some alpha releases. I can backport
some of the new features for a 1.2 release. I do want transparency in our
releases, I really don’t want to be one of those projects that make a 1.2
release where so much changes porting is inevitable.