Smalltalk › Frameworks & Tools › Seaside › Seaside Development

Configurations, changes and releases

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Johan Brichau-2

Configurations, changes and releases

Hi everyone,

Over the past month, when working towards 3.1.2, several people have contributed changes to keep Seaside working for Magritte, Pier, Pharo 4, Squeak, Gemstone 3.x, etc..
All of that lead to the creation of several versions of Seaside in the ConfigurationOfSeaside3, making several changes over baselines and versions.

As I noticed changes to existing baselines and versions, I found it very difficult to see what exactly was happening.
I think it's great to have new versions fast, but we should make sure everyone is on the same track.
In the past, mistakes have been made where modifications to already published versions caused havoc downstream.

Diego and Stephan reached out last week to discuss a policy and we agreed to have a discussion on the mailinglist.

First off, the Seaside team had already set up some development practices [3] and a release process [1][2].
I think these are still applicable but we might fine-tune them some more. Here are my proposed additions:

- no changes to baselines that have a dependent released version (we really need to consider those sealed)
- send a quick note to the mailinglist when you are changing the configuration or when you release a version (this avoids surprises with other team members)

I will also shamelessly plug here that we would be better of working with the github repository, using pull requests [4]. Right now, we are using github as the reference repository for Seaside and Grease in Gemstone and it's the only place I notice if something breaks in Squeak (the master branch is running travis tests for Pharo and Squeak).

Johan

[1] https://code.google.com/p/seaside/wiki/MakeRelease
[2] #DevelopmentProcess in ConfigurationOfSeaside3
[3] https://code.google.com/p/seaside/wiki/CodingConventions
[4] https://github.com/glassdb/Seaside31_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Tobias Pape

Re: Configurations, changes and releases

Hi,

On 06.07.2014, at 20:12, Johan Brichau <[hidden email]> wrote:

> Hi everyone,
>
> Over the past month, when working towards 3.1.2, several people have contributed changes to keep Seaside working for Magritte, Pier, Pharo 4, Squeak, Gemstone 3.x, etc..
> All of that lead to the creation of several versions of Seaside in the ConfigurationOfSeaside3, making several changes over baselines and versions.
>
> As I noticed changes to existing baselines and versions, I found it very difficult to see what exactly was happening.
> I think it's great to have new versions fast, but we should make sure everyone is on the same track.
> In the past, mistakes have been made where modifications to already published versions caused havoc downstream.
>
> Diego and Stephan reached out last week to discuss a policy and we agreed to have a discussion on the mailinglist.
>
> First off, the Seaside team had already set up some development practices [3] and a release process [1][2].
> I think these are still applicable but we might fine-tune them some more. Here are my proposed additions:
>
> - no changes to baselines that have a dependent released version (we really need to consider those sealed)
> - send a quick note to the mailinglist when you are changing the configuration or when you release a version (this avoids surprises with other team members)
>
> I will also shamelessly plug here that we would be better of working with the github repository, using pull requests [4]. Right now, we are using github as the reference repository for Seaside and Grease in Gemstone and it's the only place I notice if something breaks in Squeak (the master branch is running travis tests for Pharo and Squeak).
>
> Johan
>
> [1] https://code.google.com/p/seaside/wiki/MakeRelease
> [2] #DevelopmentProcess in ConfigurationOfSeaside3
> [3] https://code.google.com/p/seaside/wiki/CodingConventions
> [4] https://github.com/glassdb/Seaside31

Ok, I see that I missed things when I put in the small WebClient change.
Thanks for that reminder :)

Best
-Tobias

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

signature.asc (1K) Download Attachment

Philippe Marschall

Re: Configurations, changes and releases

In reply to this post by Johan Brichau-2

On Sun, Jul 6, 2014 at 8:12 PM, Johan Brichau <[hidden email]> wrote:

Sounds reasonable.

> I will also shamelessly plug here that we would be better of working with the github repository, using pull requests [4]. Right now, we are using github as the reference repository for Seaside and Grease in Gemstone and it's the only place I notice if something breaks in Squeak (the master branch is running travis tests for Pharo and Squeak).

Ok, I'll bite. What do I need to get started? What is the merge driver
and how do I use it? How can I get an .mcz again (I assume VASt and VW
will still need an MCZ).

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Johan Brichau-2

Re: Configurations, changes and releases

On 10 Jul 2014, at 14:29, Philippe Marschall <[hidden email]> wrote:

>> I will also shamelessly plug here that we would be better of working with the github repository, using pull requests [4]. Right now, we are using github as the reference repository for Seaside and Grease in Gemstone and it's the only place I notice if something breaks in Squeak (the master branch is running travis tests for Pharo and Squeak).
>
> Ok, I'll bite. What do I need to get started? What is the merge driver
> and how do I use it? How can I get an .mcz again (I assume VASt and VW
> will still need an MCZ).

Great ;-)

In addition to [1][2], a quick getting started guide:

1. Clone the Seaside github repository
2. Open a Pharo3 and create a filetree repository on '/repository' directory of the github working copy
3. Load Seaside3:
Metacello new
baseline: 'Seaside3';
repository: 'filetree://<path to repository';
load: 'CI'

The thing to mind from now on is that:
- you only have 1 version of all packages in the filetree repository
- merging is done by git (not monticello)
- the flow is:
* publish changes to your filetree repository
* commit your changes in git
* pull in changes from origin
* reload the code using Metacello in your image

All of this is still a bit rough around the edges, but when you follow the flow, I find the advantages far greater.
Just yesterday, I had to trace 'lost' changes and github tools just beat monticello tools in every aspect for that.
Branching and pull requests are an even greater advantage.

You can make MCZ by copying packages from a monticello repository to a filetree repository. As such, it can be automated using Gofer and Metacello.

We can fine-tune at ESUG, but it's good to have a bite at it beforehand.

Cheers
Johan

[1] https://github.com/dalehenrich/metacello-work/blob/master/docs/GettingStartedWithGitHub.md
[2] https://github.com/ThierryGoubier/GitFileTree-MergeDriver_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Johan Brichau-2

Re: Configurations, changes and releases

In reply to this post by Philippe Marschall

Hi,

Any more ideas/comments?

Of course, ESUG is around the corner. I know Philippe, Dale and I are going.
Who else is going?

Johan

On 10 Jul 2014, at 14:29, Philippe Marschall <[hidden email]> wrote:

> On Sun, Jul 6, 2014 at 8:12 PM, Johan Brichau <[hidden email]> wrote:
>> Hi everyone,
>>
>> Over the past month, when working towards 3.1.2, several people have contributed changes to keep Seaside working for Magritte, Pier, Pharo 4, Squeak, Gemstone 3.x, etc..
>> All of that lead to the creation of several versions of Seaside in the ConfigurationOfSeaside3, making several changes over baselines and versions.
>>
>> As I noticed changes to existing baselines and versions, I found it very difficult to see what exactly was happening.
>> I think it's great to have new versions fast, but we should make sure everyone is on the same track.
>> In the past, mistakes have been made where modifications to already published versions caused havoc downstream.
>>
>> Diego and Stephan reached out last week to discuss a policy and we agreed to have a discussion on the mailinglist.
>>
>> First off, the Seaside team had already set up some development practices [3] and a release process [1][2].
>> I think these are still applicable but we might fine-tune them some more. Here are my proposed additions:
>>
>> - no changes to baselines that have a dependent released version (we really need to consider those sealed)
>> - send a quick note to the mailinglist when you are changing the configuration or when you release a version (this avoids surprises with other team members)
>
> Sounds reasonable.
>
>> I will also shamelessly plug here that we would be better of working with the github repository, using pull requests [4]. Right now, we are using github as the reference repository for Seaside and Grease in Gemstone and it's the only place I notice if something breaks in Squeak (the master branch is running travis tests for Pharo and Squeak).
>
> Ok, I'll bite. What do I need to get started? What is the merge driver
> and how do I use it? How can I get an .mcz again (I assume VASt and VW
> will still need an MCZ).
>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Stephan Eggermont-3

Re: Configurations, changes and releases

In reply to this post by Johan Brichau-2

Johan wrote:
>Who else is going?
Diego and I will be there, but only early (from camp smalltalk on, not afterwards).

>It seems that now is a good time to release 3.1.2.

Good idea.

It would be nice to have dependent packages (Sport) also use release versions
instead of numbered. And moving up stable and development is likely to make
Seaside on Pharo 4 green too.
https://ci.inria.fr/pharo-contribution/job/Pharo4Seaside/

Stephan

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

John O'Keefe

Re: Configurations, changes and releases

In reply to this post by Johan Brichau-2

I will be there. I am also very interested in the discussion of stable versions since it is quite frustrating to us and our customers for us to say "VA Smalltalk Vy.y provides Seaside Vx.x" and then find out that Vx.x has changed after our porting (and after being declared 'stable') and so our claim is incorrect.

John O'Keefe [|], CTO/Principal Smalltalk Architect, Instantiations Inc.
Skype: john_okeefe2 Mobile: +1 919 417-3181 (Business hours USA Eastern Time zone (GMT -5))
[hidden email]
http://www.instantiations.com
VA Smalltalk...Onward and Upward!

On Fri, Jul 11, 2014 at 6:43 AM, Johan Brichau <[hidden email]> wrote:

Hi,

Any more ideas/comments?

Of course, ESUG is around the corner. I know Philippe, Dale and I are going.
Who else is going?

Johan

On 10 Jul 2014, at 14:29, Philippe Marschall <[hidden email]> wrote:

> On Sun, Jul 6, 2014 at 8:12 PM, Johan Brichau <[hidden email]> wrote:
>> Hi everyone,
>>
>> Over the past month, when working towards 3.1.2, several people have contributed changes to keep Seaside working for Magritte, Pier, Pharo 4, Squeak, Gemstone 3.x, etc..
>> All of that lead to the creation of several versions of Seaside in the ConfigurationOfSeaside3, making several changes over baselines and versions.
>>
>> As I noticed changes to existing baselines and versions, I found it very difficult to see what exactly was happening.
>> I think it's great to have new versions fast, but we should make sure everyone is on the same track.
>> In the past, mistakes have been made where modifications to already published versions caused havoc downstream.
>>
>> Diego and Stephan reached out last week to discuss a policy and we agreed to have a discussion on the mailinglist.
>>
>> First off, the Seaside team had already set up some development practices [3] and a release process [1][2].
>> I think these are still applicable but we might fine-tune them some more. Here are my proposed additions:
>>
>> - no changes to baselines that have a dependent released version (we really need to consider those sealed)
>> - send a quick note to the mailinglist when you are changing the configuration or when you release a version (this avoids surprises with other team members)
>
> Sounds reasonable.
>
>> I will also shamelessly plug here that we would be better of working with the github repository, using pull requests [4]. Right now, we are using github as the reference repository for Seaside and Grease in Gemstone and it's the only place I notice if something breaks in Squeak (the master branch is running travis tests for Pharo and Squeak).
>
> Ok, I'll bite. What do I need to get started? What is the merge driver
> and how do I use it? How can I get an .mcz again (I assume VASt and VW
> will still need an MCZ).
>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev