[Seaside-dev] Seaside 3.1 and beyond

[Johan Brichau]

Hi Philippe,

The question now becomes: how to manage a 3.1.x and 3.2 version in the repository?

My proposal would be to use a branch on github for developing 3.2. 

We have the current 3.1.x packages on github already [1]. The idea is that the master branch always has the current Seaside production version (now coming from the Smalltalkhub repo). There already is a branch for the gemstone3.1 port and my proposal to you is to use a branch for Seaside 3.2 as well. We have automated tests using Travis CI [2]. It would also mean that other people sending in patches for Seaside would use a fork & pull-request. imho, a very convenient way to collaborate and avoid unwanted changes to the repository.

What do you think?

Johan

On 06 Feb 2014, at 10:32, Philippe Marschall <philippe.marschall at gmail.com> wrote:

> On Wed, Feb 5, 2014 at 9:00 PM, Johan Brichau <johan at inceptive.be> wrote:
>> Hi Philippe,
>> 
>> Sounds very interesting. Great work as usual!
>> It's a good idea to keep it for 3.2 and settle that around ESUG.
>> 
>> I'm also interested to know if there is a fundamental problem to port it to Gemstone?
> 
> The same reason the current cache doesn't work as well: multiple
> transactions modifying the same data structure will give you a lot of
> conflicts. I don't know enough about rc-collections to come up with a
> design that would work well on Gemston. OTOH if we manage to get rid
> of the need for #keyAtValue:ifAbsent: at least the Gemstone specific
> cache should become simple.
> 
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev