On 01/19/2011 11:37 PM, Norbert Hartl wrote:
On 19.01.2011, at 19:01, Dale Henrichs wrote:
I think that the a good working model is to store the
ConfigurationOfXXX in the project repository along with the
project mcz files.
When a new version is released the configuration should be copied
to MetacelloRepository for the Pharo and Squeak community. I have
a GemSource MetacelloRepository where I put copies of
configurations that have been ported to GemStone .... when a new
version for GemStone is available.
I would not recommend that configurations be removed from
MetacelloRepository as that could break existing configurations
that expect to find the configuration there. So if it is found
that there are out-of-date configurations in MetacelloRepository, a
new version of the configuration should be copied into
MetacelloRepository.
Now that Metacello is more established, I don't think that it is
critical to require that all configurations be copied to
MetacelloRepository.
It still is useful to have a sort of clearinghouse for
configurations and until a better solution comes along it serves
that purpose. BTW, I think Stef has plans to provide better
solutions for Pharo...
I understand what you are saying and I partially agree. But it just
doesn't feel right and this is easy to show. In this example of
ConfigurationOfXMLSupport there was not one caring person like you
are that does everything and has on overview. There is a
Configuration in MetacelloRepository than it was decided to keep the
main Configuration file in XMLSupport repository. Development took
place in the XMLSupport repository. In the meantime someone changed
the Configuration in MetacelloRepsository probably for integration
purposes. Now the Configuration has been copied from XMLSupport and
has overwritten the changes that have been made to the existing
Configuration. That is what you get if you branch off things.
I don't know how to solve this properly because I didn't have time
to follow the metacello discussions. But if there is a possibility
to specify the stable for pharo 1.1.1 that doesn't change even if
the packages evolves I can't see much reason to have a writable
version of the Configuration in MetacelloRepository.
Norbert
I understand that there are potential problems using distributed version
control, but one of the reasons that I chose to use code for specifying
Metacello configurations is thatit made it possible to use Monticello
merge facilities to reconcile changes mad in different branches ...
This was a breakdown in procedure ... the intent of MetacelloRepository
is not to create branches of configurations...if I recall, there was a
change in the developers that coincided with the creation of metacello
configurations ...
I would hope that this case be classed as a learning experience rather
than a condemnation of process.
I agree that there could be a better way, but I think that the better
way involves tools support and until we get the tools we must resort to
process ...
Dale
On 01/19/2011 06:12 AM, laurent laffont wrote:
On Wed, Jan 19, 2011 at 2:49 PM, Norbert Hartl<[email protected]
<mailto:[email protected]>> wrote:
On 19.01.2011, at 14:30, laurent laffont wrote:
On Wed, Jan 19, 2011 at 1:37 PM, Norbert
Hartl<[email protected] <mailto:[email protected]>> wrote:
It depends where you look at. ConfigurationOfXMLSupport exists
in MetacelloRepository as well as in XMLSupport. The latter
one being the official one, the former one being very outdated.
My sugesstion would be to remove ConfigurationOfXMLSupport
from MetacelloRepository to lower the confusion.
Personnally I always look in MetacelloRepository, this should
be the reference IMHO.
Laurent,
I think it is up to the maintainers where to put those files.
And in the XMLSupport case the decision was made deliberately not
to put it in MetacelloRepository but in XMLSupport. The only
thing I want to avoid is having multiple different files floating
around that are edited in an inconsistent way.
I thought that all ConfigurationOfXXX working for Pharo should
be put in MetacelloRepository so we have a central place to look
at.
But I may be wrong. Mariano ? Dale ?
Laurent
Norbert
Norbert
On 19.01.2011, at 13:18, Tudor Girba wrote:
The last version 1.1.6 is marked as #release.
Cheers, Doru
On 19 Jan 2011, at 12:26, laurent laffont wrote:
I put ConfigurationOfXMLSupport version 1.0 because
blessing was #release. But I agree to change.
Laurent
On Wed, Jan 19, 2011 at 12:15 PM, Marcus Denker
<[email protected]<mailto:[email protected]>> wrote:
On Jan 19, 2011, at 11:43 AM, Tudor Girba wrote:
Indeed, this is a problem for Moose in general. We
depend
on XMLSupport, but now we cannot update it in PharoDev. I
would also strongly support the idea of removing XMLSupport
from PharoDev.
What would be important: we need the latest version in
Pharo 1.2... else how can we ever have a version where the
tests are green?
(not of XML, but in general)
Marcus
Cheers, Doru
On 19 Jan 2011, at 11:32, Fabrizio Perin wrote:
Hi,
I have a problem with the XMLSupport version from
Pharo 1.2.
The problem is that I need to work with one of the
last
version of XMLSupport but in the pharo image 1.2 is loaded an
old version of XMLSupport (I mean a version from Jan 2010). I
did try to load a newer version of XMLSupport using
ConfigurationOfXMLSupport but some errors make this operation
impossible.
So either Pharo-dev 1.2 load a newer (possibly the
last)
version of XMLSupport by default or Pharo-dev 1.2 should not
load XMLSupport at all.
I think that doesn't make sense to use by default such
an
old version, also considering that the last XMLSupport has
nice and useful features like the XMLPluggableElementFactory.
By avoiding to load XMLSupport in Pharo-dev 1.2 by
default you let people free to use the version that they like.
Thanks,
Fabrizio
-- www.tudorgirba.com<http://www.tudorgirba.com/>
"We cannot reach the flow of things unless we let go."
-- Marcus Denker -- http://www.marcusdenker.de
<http://www.marcusdenker.de/>
INRIA Lille -- Nord Europe. Team RMoD.
-- www.tudorgirba.com<http://www.tudorgirba.com/>
"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."
