So where is the "release" version of 3.7?

> Dale Henrichs wrote:
>
>> Not to complicate the discussion too much, but...
>>
>> As many of you already know, we are porting Seaside to Gemstone. As
>> part of that effort we have decided to port Monticello to Gemstone as
>> well.
>>
>
> This is interesting.
>
> What level of support is GemStone planning on providing for Seaside?  
> (i.e., will it be an unsupported goodie, or fully supported by
> GemStone, or something inbetween?)
>
> Nevin
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> 2007/2/27, Dale Henrichs <[hidden email]>:
>
>> Not to complicate the discussion too much, but...
>>
>> As many of you already know, we are porting Seaside to Gemstone. As part
>> of that effort we have decided to port Monticello to Gemstone as well.
>>
>> We want to make it easy for folks to move their applications from a
>> Squeak image to a Gemstone image and Monticello seems to be a natural
>> fit.
>>
>> Of course, this adds an extra dimension to the naming issue: because of
>> platform differences, there will be some monticello packages that are
>> Gemstone specific (today _all_ monticello packages are Squeak specific).
>>
>> The fundamental question is should the platform be encoded in the name
>> (i.e., Package_gemstone.branch-author.99) or not (implied by the
>> branch)?
>>
>> For example, I have a version of seaside stored in
>> Seaside2.6g-dkh.18.mcz. This version contains Squeak source and has as
>> an ancestor Seaside2.6a3-avi.73.mcz. There will be an equivalent version
>> that contains the Gemstone source.
>>
>> After the discussion of the last few days, I assume that the squeak
>> version should be stored in a package called Seaside2.6a3-dkh.74.mcz,
>> since it contains code that is rooted in the 6a3 branch.
>>
>> My question is what should the version of the Gemstone code be called?
>> It will be functionally equivalent to Seaside2.6a3-dkh.74.mcz, but will
>> contain Gemstone specific code.
>>
>> BTW, we already plan on hosting a Gemstone SqueakSource site, so that we
>> don't pollute the site with gemstone-specific packages.
>
>
> Will that SqueakSource run on Gemstone by chance? You see, we are
> looking into porting SqueakSource to Seaside 2.7 (which would probably
> mean rewriting the whole UI) and the model is quite simple (only 12
> classes). Additionally we are looking for some real persistence
> solution. So if you need some kind of demo application .... ;)
>
> Philippe
>
>> I think that the version name should share a common branch and package
>> name with a platform designator...
>>
>> What do you folks think?
>>
>> Dale
>> _______________________________________________
>> Seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> Philippe,
>
> As a matter of fact, we are getting real close to taking a serious  
> look at porting SqueakSource to Gemstone.
>
> We are interested in taking an existing Seaside application and  
> porting it to Gemstone, to get a better feel for how hard/easy it  
> will be and since we are planning on having a SqueakSource site for  
> Gemstone-specific code, SqueakSource would be a natural choice. On  
> top of that I am intrigued by the idea of providing a Gemstone-
> based repository for Monticello, so again SqueakSource would be the  
> natural application for leveraging a Gemstone-based monticello  
> repository.
>
> It is more likely that we will base our port on the existing set of  
> packages for SqueakSource, but the lessons we learn from that port  
> can be applied to anything done for 2.7.
>
> Dale
>
> Philippe Marschall wrote:
>
>> 2007/2/27, Dale Henrichs <[hidden email]>:
>>
>>> Not to complicate the discussion too much, but...
>>>
>>> As many of you already know, we are porting Seaside to Gemstone.  
>>> As part
>>> of that effort we have decided to port Monticello to Gemstone as  
>>> well.
>>>
>>> We want to make it easy for folks to move their applications from a
>>> Squeak image to a Gemstone image and Monticello seems to be a  
>>> natural fit.
>>>
>>> Of course, this adds an extra dimension to the naming issue:  
>>> because of
>>> platform differences, there will be some monticello packages that  
>>> are
>>> Gemstone specific (today _all_ monticello packages are Squeak  
>>> specific).
>>>
>>> The fundamental question is should the platform be encoded in the  
>>> name
>>> (i.e., Package_gemstone.branch-author.99) or not (implied by the  
>>> branch)?
>>>
>>> For example, I have a version of seaside stored in
>>> Seaside2.6g-dkh.18.mcz. This version contains Squeak source and  
>>> has as
>>> an ancestor Seaside2.6a3-avi.73.mcz. There will be an equivalent  
>>> version
>>> that contains the Gemstone source.
>>>
>>> After the discussion of the last few days, I assume that the squeak
>>> version should be stored in a package called Seaside2.6a3-dkh.
>>> 74.mcz,
>>> since it contains code that is rooted in the 6a3 branch.
>>>
>>> My question is what should the version of the Gemstone code be  
>>> called?
>>> It will be functionally equivalent to Seaside2.6a3-dkh.74.mcz,  
>>> but will
>>> contain Gemstone specific code.
>>>
>>> BTW, we already plan on hosting a Gemstone SqueakSource site, so  
>>> that we
>>> don't pollute the site with gemstone-specific packages.
>>
>>
>> Will that SqueakSource run on Gemstone by chance? You see, we are
>> looking into porting SqueakSource to Seaside 2.7 (which would  
>> probably
>> mean rewriting the whole UI) and the model is quite simple (only 12
>> classes). Additionally we are looking for some real persistence
>> solution. So if you need some kind of demo application .... ;)
>>
>> Philippe
>>
>>> I think that the version name should share a common branch and  
>>> package
>>> name with a platform designator...
>>>
>>> What do you folks think?
>>>
>>> Dale
>>> _______________________________________________
>>> Seaside mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>> _______________________________________________
>> Seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> On 2/26/07, Avi Bryant <[hidden email]> wrote:
>
>> Ok, but there are processes that work for that too.  Have a branch
>> that is 2.7-stable, and generally commit to that.  If you're doing a
>> refactoring or feature you're not sure about, do it on
>> 2.7-somerefactoring, then merge in when you're confident of it.  The
>> important thing is just that everyone know what the system is.
>
> Let me hasten to add that I am more responsible than anyone for the
> ad-hoc release culture here.  Now that I'm in a less active role, it's
> easy to preach from the sidelines :).  But we've grown a lot (this
> list is nearly 600 strong, now), so we can probably afford to clean up
> our act a little.
>
> Avi
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> I think the ad-hoc release culture that seaside currently has is a huge
> benefit and advantage.  Lukas usually has what ever bug I find fixed
> before I get the email update.  What needs to stop is the need of
> updating from Monticello.  Other open source projects use CVS or
> Subversion, but when you go to their site how many recommend you
> download from the repository?  Most give it as an option, but nearly all
> have a separate place for getting the latest
> stable/unstable/foo-only/etc.  This what needs to get adopted and this
> would allow folks that are in a position to know to update the package,
> so that people who can't keep up with it don't have to.

> 2007/2/28, Jason Johnson <[hidden email]>:
>> I think the ad-hoc release culture that seaside currently has is a huge
>> benefit and advantage.  Lukas usually has what ever bug I find fixed
>> before I get the email update.  What needs to stop is the need of
>> updating from Monticello.  Other open source projects use CVS or
>> Subversion, but when you go to their site how many recommend you
>> download from the repository?  Most give it as an option, but nearly all
>> have a separate place for getting the latest
>> stable/unstable/foo-only/etc.  This what needs to get adopted and this
>> would allow folks that are in a position to know to update the package,
>> so that people who can't keep up with it don't have to.
>
> This is what SqueakMap is for.
>