What evidence do you have for that statement? That seems very
subjective, and may be you do not like the structure. Avogadro has a
growing number of users, not all of them release their code formally,
never mind get it into a distro. Does that mean we should not support
them? Do you think they will continue using it if everything is
constantly in flux?
Note, that plugin development is not affected at all - everything was
done properly in build system integration
–
Regards,
Konstantin
Hi,
Some of the changes in master have broken linking in Kalzium, I just went over
a report from a developer. Through the 1.x series, I thought at a minimum we
would preserve API/linking. It looks like it is the work splitting the
periodic table widget out from the main library. Whilst I appreciate the
motivation I do not think we should be removing public API (or breaking it),
as this creates too much of a moving target for people developing against
Avogadro.
I don’t want to dictate what should be done, but I do feel like breaking
API/linking of existing code should be restricted to major releases/rewrites,
i.e. 2.0, 3.0 etc. I was hoping to preserve ABI too, but always accepted that
would be tough, and may not be possible with every minor release. In those
cases we would announce it, and bump the SO number so as to allow distros to
keep things working.
Kalzium is not yet released, so I could make some changes to help it link. I
don’t think it is acceptable to move existing symbols/API out of the Avogadro
library in general. I would like to move the periodic table stuff back into
Avogadro, if we really need a separate lib with just the periodic table, then
we can do some namespace magic to prevent symbol collisions.
Thoughts from others?
Marcus
On Sat, May 22, 2010 at 9:56 AM, Marcus D. Hanwell marcus@cryos.org wrote:
Hi,
Some of the changes in master have broken linking in Kalzium, I just went over
a report from a developer. Through the 1.x series, I thought at a minimum we
would preserve API/linking. It looks like it is the work splitting the
periodic table widget out from the main library. Whilst I appreciate the
motivation I do not think we should be removing public API (or breaking it),
as this creates too much of a moving target for people developing against
Avogadro.I don’t want to dictate what should be done, but I do feel like breaking
API/linking of existing code should be restricted to major releases/rewrites,
i.e. 2.0, 3.0 etc. I was hoping to preserve ABI too, but always accepted that
would be tough, and may not be possible with every minor release. In those
cases we would announce it, and bump the SO number so as to allow distros to
keep things working.
I totally agree. API/ABI breaking can be really problematic for
downstream Linux distributors. It can have an adverse affect on
adoption of newer versions. It’s hard enough making sure latest
Avogadro is in Ubuntu, having to do SONAME transitions makes it just
that much harder. It’s also difficult for wanting to build code on
stable libraries. While it can be initially exciting to see great new
features coming down the pipe, once you’ve built stable software is
very inconvenient to have the library moving beneath you.
That said, I think Marcus laid out a pretty good versioning scheme
that allows people to do all kinds of work on Avogadro, it just needs
to be done in the right branch.
-Jordan
On Sat, 22 May 2010 09:56:26 -0400
“Marcus D. Hanwell” marcus@cryos.org wrote:
Hi,
Some of the changes in master have broken linking in Kalzium, I just
went over a report from a developer. Through the 1.x series, I
thought at a minimum we would preserve API/linking. It looks like it
is the work splitting the periodic table widget out from the main
library. Whilst I appreciate the motivation I do not think we should
be removing public API (or breaking it), as this creates too much of
a moving target for people developing against Avogadro.
IMHO, developing with Avogadro as of 1.0.x series is a pain for those
who only need widget for drawing of molecules. Avogadro’s widget
(especially, compiled with Python support) loads into memory whole bunch
of dependencies and plugins. Please, read my page “Refactoring Ideas” in
wiki about modularization
I think, Kalzium people could wait a bit before they get a widget which
is nice to work with
I didn’t removed any API. If some headers are moved to other
directories, their copies are still in include/avogadro
Kalzium is not yet released, so I could make some changes to help it
link.
I think Kalzium build could be changed. Is it so difficult to add
library?
I don’t think it is acceptable to move existing symbols/API out
of the Avogadro library in general. I would like to move the periodic
table stuff back into Avogadro, if we really need a separate lib with
just the periodic table, then we can do some namespace magic to
prevent symbol collisions.
I think we could build “old-style” monolithic library alongside with new
modular. Maybe you know, how to force stupid cmake don’t recompile
everything twice?
–
Regards,
Konstantin
On Saturday 22 May 2010 10:56:15 Konstantin Tokarev wrote:
On Sat, 22 May 2010 09:56:26 -0400
“Marcus D. Hanwell” marcus@cryos.org wrote:
Hi,
Some of the changes in master have broken linking in Kalzium, I just
went over a report from a developer. Through the 1.x series, I
thought at a minimum we would preserve API/linking. It looks like it
is the work splitting the periodic table widget out from the main
library. Whilst I appreciate the motivation I do not think we should
be removing public API (or breaking it), as this creates too much of
a moving target for people developing against Avogadro.IMHO, developing with Avogadro as of 1.0.x series is a pain for those
who only need widget for drawing of molecules. Avogadro’s widget
(especially, compiled with Python support) loads into memory whole bunch
of dependencies and plugins. Please, read my page “Refactoring Ideas” in
wiki about modularizationI think, Kalzium people could wait a bit before they get a widget which
is nice to work withI didn’t removed any API. If some headers are moved to other
directories, their copies are still in include/avogadro
The API is removed from the library - the symbols are no longer there. When
you package and distribute a library, this is generally not done as it makes
developing against that library more difficult.
ABI break - recompile, relink, all is well.
API break - port your code/build system, recompile, relink, all is well.
Porting code because one of your upstream libraries keeps moving things around
makes you question how much you are getting from reusing their code.
Kalzium is not yet released, so I could make some changes to help it
link.I think Kalzium build could be changed. Is it so difficult to add
library?
It could be changed, you missed my point that I am not sure it should be
necessary to change. We released 1.0, and at a minimum said API would be
preserved, and that we would do everything we could to preserve ABI. I know
you were not around for the 2+ years of development effort to get to that
point, and may not agree with every decision.
I don’t think it is acceptable to move existing symbols/API out
of the Avogadro library in general. I would like to move the periodic
table stuff back into Avogadro, if we really need a separate lib with
just the periodic table, then we can do some namespace magic to
prevent symbol collisions.I think we could build “old-style” monolithic library alongside with new
modular. Maybe you know, how to force stupid cmake don’t recompile
everything twice?
I don’t agree that CMake is stupid, and am not sure why you are trying to
attack it. Say I do what you say, and create two libraries with the same
object in it, what do you think would happen if I linked an executable with
both libraries? Say Kalzium used the old one in the Avogadro library, and an
Avogadro plugin Kalzium used loaded the new one?
It should be compiled twice, using two different namespaces so that the symbol
names do not collide. One in the Avogadro library, with the Avogadro
namespace, and again in the split library with a different namespace. So then
if a library were to load both libraries there would be no problem.
There are ways to only compile once, but in this instance that is not the
correct course of action. I do think you underestimate the value of keeping a
library’s API stable at a minimum. I have worked on Linux packaging for many
years, and would say my experience in that arena gives me some added insight.
Marcus
On Sat, 22 May 2010 10:41:34 -0400
Jordan Mantha jordan.mantha@gmail.com wrote:
On Sat, May 22, 2010 at 9:56 AM, Marcus D. Hanwell marcus@cryos.org
wrote:Hi,
Some of the changes in master have broken linking in Kalzium, I
just went over a report from a developer. Through the 1.x series, I
thought at a minimum we would preserve API/linking. It looks like
it is the work splitting the periodic table widget out from the
main library. Whilst I appreciate the motivation I do not think we
should be removing public API (or breaking it), as this creates too
much of a moving target for people developing against Avogadro.I don’t want to dictate what should be done, but I do feel like
breaking API/linking of existing code should be restricted to major
releases/rewrites, i.e. 2.0, 3.0 etc. I was hoping to preserve ABI
too, but always accepted that would be tough, and may not be
possible with every minor release. In those cases we would announce
it, and bump the SO number so as to allow distros to keep things
working.I totally agree. API/ABI breaking can be really problematic for
downstream Linux distributors. It can have an adverse affect on
adoption of newer versions. It’s hard enough making sure latest
Avogadro is in Ubuntu, having to do SONAME transitions makes it just
that much harder.
Don’t forget about stable branch. All fixes are backported, and ABI
stability is being kept. Also, it doesn’t seem that trunk will be
released soon (am I wrong?)
It’s also difficult for wanting to build code on
stable libraries.
Avogadro trunk may be built against stable OpenBabel
While it can be initially exciting to see great new
features coming down the pipe, once you’ve built stable software is
very inconvenient to have the library moving beneath you.
Is there any package in Ubuntu beyond Kalzium which uses libavogadro?
no. Why? because it’s structure is not developer-friendly
That said, I think Marcus laid out a pretty good versioning scheme
that allows people to do all kinds of work on Avogadro, it just needs
to be done in the right branch.-Jordan
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options
–
Regards,
Konstantin
On Sat, 22 May 2010 11:09:30 -0400
“Marcus D. Hanwell” marcus@cryos.org wrote:
On Saturday 22 May 2010 10:56:15 Konstantin Tokarev wrote:
On Sat, 22 May 2010 09:56:26 -0400
“Marcus D. Hanwell” marcus@cryos.org wrote:
Hi,
Some of the changes in master have broken linking in Kalzium, I
just went over a report from a developer. Through the 1.x series,
I thought at a minimum we would preserve API/linking. It looks
like it is the work splitting the periodic table widget out from
the main library. Whilst I appreciate the motivation I do not
think we should be removing public API (or breaking it), as this
creates too much of a moving target for people developing against
Avogadro.IMHO, developing with Avogadro as of 1.0.x series is a pain for
those who only need widget for drawing of molecules. Avogadro’s
widget (especially, compiled with Python support) loads into memory
whole bunch of dependencies and plugins. Please, read my page
“Refactoring Ideas” in wiki about modularizationI think, Kalzium people could wait a bit before they get a widget
which is nice to work withI didn’t removed any API. If some headers are moved to other
directories, their copies are still in include/avogadroThe API is removed from the library - the symbols are no longer
there. When you package and distribute a library, this is generally
not done as it makes developing against that library more difficult.ABI break - recompile, relink, all is well.
API break - port your code/build system, recompile, relink, all is
well.Porting code because one of your upstream libraries keeps moving
things around makes you question how much you are getting from
reusing their code.
Why it’s needed to port code in this case? all headers are in the
place, the single object of change is link flags.
Kalzium is not yet released, so I could make some changes to help
it link.I think Kalzium build could be changed. Is it so difficult to add
library?It could be changed, you missed my point that I am not sure it should
be necessary to change. We released 1.0, and at a minimum said API
would be preserved, and that we would do everything we could to
preserve ABI. I know you were not around for the 2+ years of
development effort to get to that point, and may not agree with every
decision.I don’t think it is acceptable to move existing symbols/API out
of the Avogadro library in general. I would like to move the
periodic table stuff back into Avogadro, if we really need a
separate lib with just the periodic table, then we can do some
namespace magic to prevent symbol collisions.I think we could build “old-style” monolithic library alongside
with new modular. Maybe you know, how to force stupid cmake don’t
recompile everything twice?I don’t agree that CMake is stupid, and am not sure why you are
trying to attack it. Say I do what you say, and create two libraries
with the same object in it, what do you think would happen if I
linked an executable with both libraries? Say Kalzium used the old
one in the Avogadro library, and an Avogadro plugin Kalzium used
loaded the new one?It should be compiled twice, using two different namespaces so that
the symbol names do not collide. One in the Avogadro library, with
the Avogadro namespace, and again in the split library with a
different namespace. So then if a library were to load both libraries
there would be no problem.There are ways to only compile once, but in this instance that is not
the correct course of action. I do think you underestimate the value
of keeping a library’s API stable at a minimum. I have worked on
Linux packaging for many years, and would say my experience in that
arena gives me some added insight.
I surrender, it’s very clever 
–
Regards,
Konstantin
On Saturday 22 May 2010 11:20:46 Konstantin Tokarev wrote:
On Sat, 22 May 2010 11:09:30 -0400
“Marcus D. Hanwell” marcus@cryos.org wrote:
On Saturday 22 May 2010 10:56:15 Konstantin Tokarev wrote:
On Sat, 22 May 2010 09:56:26 -0400
“Marcus D. Hanwell” marcus@cryos.org wrote:
Hi,
Some of the changes in master have broken linking in Kalzium, I
just went over a report from a developer. Through the 1.x series,
I thought at a minimum we would preserve API/linking. It looks
like it is the work splitting the periodic table widget out from
the main library. Whilst I appreciate the motivation I do not
think we should be removing public API (or breaking it), as this
creates too much of a moving target for people developing against
Avogadro.IMHO, developing with Avogadro as of 1.0.x series is a pain for
those who only need widget for drawing of molecules. Avogadro’s
widget (especially, compiled with Python support) loads into memory
whole bunch of dependencies and plugins. Please, read my page
“Refactoring Ideas” in wiki about modularizationI think, Kalzium people could wait a bit before they get a widget
which is nice to work withI didn’t removed any API. If some headers are moved to other
directories, their copies are still in include/avogadroThe API is removed from the library - the symbols are no longer
there. When you package and distribute a library, this is generally
not done as it makes developing against that library more difficult.ABI break - recompile, relink, all is well.
API break - port your code/build system, recompile, relink, all is
well.Porting code because one of your upstream libraries keeps moving
things around makes you question how much you are getting from
reusing their code.Why it’s needed to port code in this case? all headers are in the
place, the single object of change is link flags.
By porting I mean some manual intervention. In this case, it is changing a
line (conditionally - 1.0/1.1+ differ) in a build script. That is still
porting, but not a massive effort. In this case no actual C++ code needs to
change.
Kalzium is not yet released, so I could make some changes to help
it link.I think Kalzium build could be changed. Is it so difficult to add
library?It could be changed, you missed my point that I am not sure it should
be necessary to change. We released 1.0, and at a minimum said API
would be preserved, and that we would do everything we could to
preserve ABI. I know you were not around for the 2+ years of
development effort to get to that point, and may not agree with every
decision.I don’t think it is acceptable to move existing symbols/API out
of the Avogadro library in general. I would like to move the
periodic table stuff back into Avogadro, if we really need a
separate lib with just the periodic table, then we can do some
namespace magic to prevent symbol collisions.I think we could build “old-style” monolithic library alongside
with new modular. Maybe you know, how to force stupid cmake don’t
recompile everything twice?I don’t agree that CMake is stupid, and am not sure why you are
trying to attack it. Say I do what you say, and create two libraries
with the same object in it, what do you think would happen if I
linked an executable with both libraries? Say Kalzium used the old
one in the Avogadro library, and an Avogadro plugin Kalzium used
loaded the new one?It should be compiled twice, using two different namespaces so that
the symbol names do not collide. One in the Avogadro library, with
the Avogadro namespace, and again in the split library with a
different namespace. So then if a library were to load both libraries
there would be no problem.There are ways to only compile once, but in this instance that is not
the correct course of action. I do think you underestimate the value
of keeping a library’s API stable at a minimum. I have worked on
Linux packaging for many years, and would say my experience in that
arena gives me some added insight.I surrender, it’s very clever
I wasn’t claiming CMake was perfect, but a lot of time, effort, and money has
gone into it. I work at Kitware, and we use it for some enormous projects.
Like any major software project, it has bugs and features that are not yet
ready/implemented. That said it is powerful.
Another example of backwards compatibility comes from CMake itself, the policy
framework is there so that they can break backwards compatibility, but allow
the user to choose when. So you don’t have to port your CMake files with every
release, because then you have a build system no one wants to use - a moving
target you can never quite catch. See my point? The policies create quite a
bit of extra work (maintaining two behaviors long term), but are necessary to
keep users happy.
I am possibly rambling now, but backwards compatibility is important in
reusable components is my point. It can drain resources, and that is where you
need to make a call. It is not a rule that can never be broken.
Marcus
On Saturday 22 May 2010 11:12:27 Konstantin Tokarev wrote:
On Sat, 22 May 2010 10:41:34 -0400
Jordan Mantha jordan.mantha@gmail.com wrote:
While it can be initially exciting to see great new
features coming down the pipe, once you’ve built stable software is
very inconvenient to have the library moving beneath you.Is there any package in Ubuntu beyond Kalzium which uses libavogadro?
no. Why? because it’s structure is not developer-friendly
What evidence do you have for that statement? That seems very subjective, and
may be you do not like the structure. Avogadro has a growing number of users,
not all of them release their code formally, never mind get it into a distro.
Does that mean we should not support them? Do you think they will continue
using it if everything is constantly in flux?
Marcus
On Sat, 22 May 2010 11:43:17 -0400
“Marcus D. Hanwell” marcus@cryos.org wrote:
On Saturday 22 May 2010 11:12:27 Konstantin Tokarev wrote:
On Sat, 22 May 2010 10:41:34 -0400
Jordan Mantha jordan.mantha@gmail.com wrote:
While it can be initially exciting to see great new
features coming down the pipe, once you’ve built stable software
is very inconvenient to have the library moving beneath you.Is there any package in Ubuntu beyond Kalzium which uses
libavogadro? no. Why? because it’s structure is not
developer-friendlyWhat evidence do you have for that statement? That seems very
subjective, and may be you do not like the structure. Avogadro has a
growing number of users, not all of them release their code formally,
never mind get it into a distro. Does that mean we should not support
them?
Of course, no, we should. But I think it’s obvious that modular
structure is simpler and more logical. I guess many people (including
me) want to have lightweight Qt-based molecular widget which loads only
that stuff which is really needed.
Do you think they will continue using it if everything is
constantly in flux?
No flux. Have you something against an idea of parallel existence of
monolithic an modular libraries? People will see where we are moving
and change their projects some day. For 2.0, we can deprecate
monolithic library
However, I think it’ll be more reasonable to separate plot widget
permanently - there’s no chemical in it. I’ve already created Qt
Designer plugin for it, people will be able to use it without any
problems.
–
Regards,
Konstantin
What evidence do you have for that statement? That seems very
subjective, and may be you do not like the structure. Avogadro has a
growing number of users, not all of them release their code formally,
never mind get it into a distro. Does that mean we should not support
them? Do you think they will continue using it if everything is
constantly in flux?
Note, that plugin development is not affected at all - everything was
done properly in build system integration
–
Regards,
Konstantin
On Saturday 22 May 2010 11:56:42 Konstantin Tokarev wrote:
On Sat, 22 May 2010 11:43:17 -0400
“Marcus D. Hanwell” marcus@cryos.org wrote:
On Saturday 22 May 2010 11:12:27 Konstantin Tokarev wrote:
On Sat, 22 May 2010 10:41:34 -0400
Jordan Mantha jordan.mantha@gmail.com wrote:
While it can be initially exciting to see great new
features coming down the pipe, once you’ve built stable software
is very inconvenient to have the library moving beneath you.Is there any package in Ubuntu beyond Kalzium which uses
libavogadro? no. Why? because it’s structure is not
developer-friendlyWhat evidence do you have for that statement? That seems very
subjective, and may be you do not like the structure. Avogadro has a
growing number of users, not all of them release their code formally,
never mind get it into a distro. Does that mean we should not support
them?Of course, no, we should. But I think it’s obvious that modular
structure is simpler and more logical. I guess many people (including
me) want to have lightweight Qt-based molecular widget which loads only
that stuff which is really needed.
I like this approach, and am moving in that direction with some projects at
work. I also value backwards compatibility, and stability. Your previous
comment did not indicate you held them in the same regard.
Do you think they will continue using it if everything is
constantly in flux?
No flux. Have you something against an idea of parallel existence of
monolithic an modular libraries? People will see where we are moving
and change their projects some day. For 2.0, we can deprecate
monolithic library
There is flux, and you were not all that clear about the parallel existence of
modular and monolithic libraries. There are certain rules in library
maintenance we should strive to follow. For a 2.0 release it is quite
reasonable to indicate to users that they will need to port, but that isn’t
the way things have been going, and your comment did not indicate this was
what you supported doing.
However, I think it’ll be more reasonable to separate plot widget
permanently - there’s no chemical in it. I’ve already created Qt
Designer plugin for it, people will be able to use it without any
problems.
I am not anyone ever used it from outside, it is always a risk removing this
stuff. We do not know if someone developed an internally used application using
it, so even then I am loathed to remove public API. Not sure how much was
public though - we should do a better job of tracking that. Any header in the
1.0 release that was installed is part of our public API. That API should not
be broken, those symbols should all live in the library.
For 2.0 everything could be split. Qt do an awesome job, marking things to
remove/split in 5.0. It takes a lot of discipline, but that is why they are
the creators of when of the most respected C++ libraries on the market.
If we move to create a monolithic, and an optional split set, that would be
reasonable. I do hope we can avoid removing any public API (or breaking it). I
already agreed that an ABI break would happen, but never to an API/wholesale
removal of functionality from the library.
I spent a lot of time researching library design, and looking to our peers in
other areas/markets. I think we can do a lot to improve things in chemistry by
providing a powerful library, but fear the “death by a thousand splinters”
when little things keep breaking people’s dependent code in each release.
Good. reusable libraries are tough to write and maintain. It has always been
my hope to create a library for chemistry that others admire, and use widely.
Marcus
I like this approach, and am moving in that direction with some
projects at work. I also value backwards compatibility, and
stability. Your previous comment did not indicate you held them in
the same regard.
I value them too. But I think on this stage early changes are better
than delayed. And I think 3rd party developers should better rely on
1.0 than on trunk now, because we don’t have killer features in
core which are missing in stable branch (with exception of early
modularization)
–
Regards,
Konstantin
I like this approach, and am moving in that direction with some
projects at work.
Done - now avogadro-full target includes sources of plotwidget and
periodictable. But I think we should warn users that monolithic library
may be abandoned in 1.2 (or 2.0, or add another milestone here)
–
Regards,
Konstantin
On Saturday 22 May 2010 12:27:15 Konstantin Tokarev wrote:
I like this approach, and am moving in that direction with some
projects at work. I also value backwards compatibility, and
stability. Your previous comment did not indicate you held them in
the same regard.I value them too. But I think on this stage early changes are better
than delayed. And I think 3rd party developers should better rely on
1.0 than on trunk now, because we don’t have killer features in
core which are missing in stable branch (with exception of early
modularization)
I am not sure what you mean by early stage - Avogadro has been in development
for a number of years. Our 1.0 release took a lot of time, and planning. As
part of making the 1.0 release we guaranteed our API stability, and that is
one of the reasons it was delayed multiple times.
Just because there aren’t lots of high profile projects using Avogadro, does
not mean it is not being used. I know of several groups that have at least
worked on some experiemental applications using AVogadro, and they deserve our
support. They accepted in the 0.y years that the API was subject to change
(and were still unhappy when it changed), and we made a promise with 1.y
series.
There are people making funding proposals to add new features and
functionality to Avogadro. There is a growing ecosystem, and it should be
nurtured. I have spent a large amount of my time for over three years working
on Avogadro, although I have had very limited time since I moved to my new
position at Kitware last year (in late September).
I really appreciate some of your contributions, but don’t always feel that you
value the years of work that have already gone into Avogadro. I have seen too
many promising projects wither away and die because of people constantly
refactoring, and “fixing” things. There comes a point where you have to accept
some of the warts for a while, saving up your outstanding issues for major
releases.
I personally would like to begin following more coherent development patterns.
Read the gitworkflows man page, this is something we are adopting at Kitware
and it shows great promise. All features are developed in topic branches,
those topic branches are worked on, and when ready, they are merged into next.
If, after some peer review/testing, they are found to be good they are merged
into master. For more experimental changes, a pu (proposed updates) branch is
used.
If this approach were used, then may be not everything gets merged, but
several approaches can be tried. It also means that branches encapsulate
logical workflows, hopefully with descriptive commit messages summarizing what
each commit is doing. The topic branches (if branches from an early enough
point) can even be merged into next, master and maint (equivalent to our 1.0
branch).
This is the kind of workflow used by more and more projects, Jordan was
describing the workflow used by Ubuntu which seems to have some parallels. I
think this could be a great step forward, allowing us to really use some of
the new capabilities in Git, rather than using Git as a distributed subversion
workflow.
I would say that Avogadro is already quite mature, and am absolutely against
breaking the API/any existing applications if we can help it. Whether they are
high profile, or sitting on a PhD students hard drive as their first experiments
with hooking their MD code up to a visualization framework.
Marcus
On Saturday 22 May 2010 13:45:02 Konstantin Tokarev wrote:
I like this approach, and am moving in that direction with some
projects at work.Done - now avogadro-full target includes sources of plotwidget and
periodictable. But I think we should warn users that monolithic library
may be abandoned in 1.2 (or 2.0, or add another milestone here)
That also break compatibility - the target should remain avogadro, as it was
int the release. Call the other avogadro-lite or something. I will take a
look, but we should also be keeping target names consistent as this is another
thing that breaks, and then the user/developer has to go hunting.
It should be the default, until 2.0 when it could be abandoned.
Marcus
That also break compatibility - the target should remain avogadro, as
it was int the release.
avogadro - everything
is it ok?
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.
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
Regards,
Konstantin
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
plotwidget
periodictableavogadro - 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.
Thanks,
Marcus
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).
Thanks for clarifying this thing. I thought it vice versa: use
“avogadro” for AvogadroWidget to simplify porting, since “AvogadroCore”
will be linked as interface library
–
Regards,
Konstantin
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.
AFAIK, for Qt 4.5,4.6,4.7 could be called “major” releases. Why we
can’t call 1.2 “major”? And it’s better to make 1.1.x compatible with
1.2 than 1.0 (only my humble opinion)
–
Regards,
Konstantin