[Seaside] Seaside 2.7a1 versions 169

Ron Teitelbaum Ron at USMedRec.com
Mon Feb 12 15:33:19 UTC 2007


The code does work and the main line development numbers have meaning even
if you choose to ignore them.  In the past merging of branches has been done
to the largest number so by default that number has meaning.  I understand
and appreciate the benefit of forking paths and I certainly understand the
benefit of the tools ability to merge at will.  I only suggest that since
posting to the main path is intentional it should be respected and that not
bothering to include someone else's changes is bad form.

As for how I use the numbers right now Seaside is about 10% of the work I am
doing.  I'm in development and benefit from knowing what the latest changes
are so that when I'm ready to lock things down I can reproduce an image from
scratch.  It is also good for me to know what changes break things so that I
can participate in either fixing them locally or pointing them out to the
community before they are on my critical path.  There is a benefit to
continual integration and testing.

You are free to do what you want.  I certainly respect your opinion and
value your contributions.


Ron Teitelbaum 

> From: Philippe Marschall
> Sent: Monday, February 12, 2007 4:40 AM
> 2007/2/12, Ron Teitelbaum <Ron at usmedrec.com>:
> > Philippe,
> >
> > Actually no.  If you update from repositories, which my system does
> > automatically you will see that it changes back and forth from each
> version
> > of 169.
> Ah, you are talking about that functionality. That never worked
> anyway. Even if it worked it would still be a bad idea to use it. We
> don't write change logs for fun. Sometimes we do breaking changes,
> sometimes you will have to change your code, sometimes we do
> experimental versions (with comments like 'do not load') people will
> still load it and complain when it does as advertised.
> Monticello is not CVS, it does not work like CVS, there is no concept
> of CVS HEAD. The version numbers in the MCZ files are not the same as
> CVS revisions. They are merely a way on making sure the filenames are
> unique. They have _NO_ semantics (which is why you are free to choose
> anything). The semantics are all defined by the metainformation file
> and not the filename. Filename hackery is not the correct way to
> extend Monticello, it doesn't work and only leads to more problems as
> can be seen with Chronos. The right way is add more metainformation to
> a file.
> So what is the latest version of a Monticello Package anyway? It is
> the merge of all the leaves on the ancestory graph in all the
> repositories (yes all, Monticello is distributed), not the version
> with the biggest integer in the filename.
> > This means that I update every time my system loads.  It also means
> > that I have no idea which version is considered the current one.  It's
> > better if we do not release two versions with the same number, unless we
> are
> > intending to permanently fork in which case I would recommend using a
> dot
> > version 169.01 or a new name for the fork.
> > Since that is not the case could
> > we reconcile and release a new version?
> When they are ready to be merged, they will be merged. It is not the
> first time we have versions with the same version numbers and it will
> not be the last. Monticello does not force you to synch before
> committing, making every commit a branch, and it works very good this
> way.
> Cheers
> Philippe
> > Ron
> >
> > > From: Philippe Marschall
> > > Sent: Sunday, February 11, 2007 12:01 PM
> >
> > >
> > > 2007/2/11, Ron Teitelbaum <Ron at usmedrec.com>:
> > > > Hi all,
> > > > There are two version of Seaside2.7a1-nnn.169
> > > >
> > > > The pmm and mb.
> > > > Could we reconcile and merge the two versions?  Having two versions
> with
> > > the
> > > > same version number wreaks havoc with Monticello Configurations.
> > >
> > > Not to my experience since MCC takes the author initials into account.
> > > Later versions even use the UUID so even having two different versions
> > > with exactly the same filename works fine.
> > >
> >
> >
> >
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

More information about the Seaside mailing list