- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About the new release process

by Sean P. DeNigris

EstebanLM wrote > > our new release process... > two bug fix releases at month 4 and month 8... > During this year we'll also release bugfix versions of Pharo 1.4. > This is exciting because as soon as a version is released, everyone starts pounding on it and inevitably finding bugs. It will be nice to have those fixes go into the current version instead of instantly starting to focus on the next major version months or a year away. I noticed bug issues relevant to 1.4 getting tagged with 2.0 milestone. How do we get fixes into the 1.4 bug release versions? If we make a slice off the 1.4 package, there may be many conflicts merging into 2.0, but if we merge in the future version, there will be many 2.0-only changes that have nothing to do with the fix, won't there? What's the protocol? And now that we're time-based, what's the date for the first bug fix release? -- View this message in context: http://forum.world.st/About-the-new-release-process-tp4574410p4630175.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 14, 2012

Re: [Pharo-project] SSO - CAS Client in Smalltalk ?

by Sven Van Caekenberghe

Bonjour CÃ©drick, StÃ©pahane, On 14 May 2012, at 19:44, CÃ©drick BÃ©ler wrote: > I'll let you know. > > CAS seems to be kind of standard for high organization SSO. It's just sad I didn't thought of it for Google Summer of Code. This could have been an opportunity. > There's also ESUG. But maybe others should say of they find such an implementation useful (and not only me :) ). Yes, these are interesting add-on projects. The basis (Pharo+Zn+Zdc) is there, I don't think these are major undertakings, but they can get stuck on some small seemingly insurmountable detail. Step 1 is to understand the specification and the foundation to start from. Looking at implementations in other languages helps. Regards, Sven PS: CÃ©drick, I remember the OAuth (Dropbox) stuff that you were trying. Any chance to start that again ? ;-) -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

May 14, 2012

Re: [Pharo-project] SSO - CAS Client in Smalltalk ?

by CÃ©drick BÃ©ler

Hi Steph, I'll let you know. CAS seems to be kind of standard for high organization SSO. It's just sad I didn't thought of it for Google Summer of Code. This could have been an opportunity. There's also ESUG. But maybe others should say of they find such an implementation useful (and not only me :) ). Cheers, CÃ©drick Le 12 mai 2012 Ã 10:33, StÃ©phane Ducasse a Ã©crit : > Hi cedric > > Let us know because I like to get as protocol and solutions to interact with the world. May be such effort could be supported by esug too. > > > Stef > > > On May 11, 2012, at 2:18 PM, CÃ©drick BÃ©ler wrote: > >> Hi all, >> >> I'd like to develop some web apps for our university but one prerequisite is to use the Central Authentication Service [1]. It's an open source authentication service and I wonder if somebody has ever worked with it and if there are any client available. Do you have any experience and/or pointers ? >> >> If not, I may dog into the protocol and see what I can do. I've spotted PHP implementation and also Ruby [2]. >> >> I think that could be a nice addition to Zinc even if not as widespread as OAuth/OpenID stuffs. >> >> TIA >> >> CÃ©drick >> >> [1] http://en.wikipedia.org/wiki/Central_Authentication_Service >> [2] https://github.com/rubycas/rubycas-client >> >> > >

May 14, 2012

Re: [Pharo-project] Semantic Versioning

by Philippe Marschall

On 05/14/2012 05:11 PM, Sean P. DeNigris wrote: > > Philippe Marschall-2 wrote >> >> I don't think you'd be happy with the consequences. First you'd have to >> define what is API which is hard because everything is public in >> Smalltalk >> > Right, first you'd have to specify public packages/categories or individual > classes (which would be helpful with of without semantic versioning. I > sometimes find it difficult to know what classes I'm supposed to use in a > library when private helper classes pollute the package/category). Then, any > method there that's not in 'private' would be API. > > > Philippe Marschall-2 wrote >> >> And then you have to live by it which means you have much >> less freedom how you version things. >> > You'd have less freedom to choose the exact numbering, but that's the whole > point! To agree on and stick to a system, losing a little control, but > gaining clarity and usability (b.t.w. then Metacello could say "load this > dependency version 2.x.x" and know that it'd get all the bug fixes but > wouldn't break anything). Theoretically, but some of your other packages may have their own version constraints on this library. This is why installing an Eclipse plugin is np-complete (I shit you not) and a linear equitation solver [1] is used. In addition instead of of simply being an "interface consumer" (using a protocol of an object) you may be a "provider" (sublcass some abstract class). So let's say that from version 2.1.0 to 2.2.0 the library added a new abstract method that you have to implement (my understanding of SemVer is that this fine) now the code breaks because your implementation class just became abstract. Or they change their dependencies which now conflict with the dependencies of some of the dependencies of your other packages. Don't get me wrong you can make it work. But it requires commitment from everybody and most importantly good and correct metadata for everything in the image. This may sound easy but isn't. It's not just plugging something in and suddenly there are only rainbows from there on. [1] http://www.sat4j.org/ Cheers Philippe

May 14, 2012

Re: [Pharo-project] Semantic Versioning

by Dale Henrichs

----- Original Message ----- | From: "Sean P. DeNigris" <sean(a)clipperadams.com> | To: pharo-project(a)lists.gforge.inria.fr | Sent: Monday, May 14, 2012 8:11:19 AM | Subject: Re: [Pharo-project] Semantic Versioning | | | Right, first you'd have to specify public packages/categories or | individual | classes (which would be helpful with of without semantic versioning. | I | sometimes find it difficult to know what classes I'm supposed to use | in a | library when private helper classes pollute the package/category). | Then, any | method there that's not in 'private' would be API. Sean, I've always been intrigued by Interfaces in Java...not the interlocking-typing system, but the fact that the public api is explicitly called out. I would think that we could start creating a InterfaceOfXXX class that specifies the public classes and API ... perhaps the class comment would be the primary project documentation... It's a convention, but could be very useful: you can use specifications for validation of test coverage and dependency calculations... Dale

May 14, 2012

Re: [Pharo-project] Semantic Versioning

by Dale Henrichs

----- Original Message ----- | From: "Francois Stephany" <tulipe.moutarde(a)gmail.com> | To: pharo-project(a)lists.gforge.inria.fr | Sent: Monday, May 14, 2012 9:02:25 AM | Subject: Re: [Pharo-project] Semantic Versioning | | A release should maybe be a complete new entity (and not editable) | hosted somewhere else than in the code repository. The Fuel gsoc | would | probably help a lot for that. We can maybe imagine something Ã la | Ruby gems? | With the git/github work, I might be getting close to what you are looking for: ...when you reference a project hosted on github, Metacello downloads the .zip of the project directory and the FileTree repository is marked as readonly... This is awfully close to ruby gems, I think the only thing missing is that whole project directory structure is downloaded instead of just the deployment artifacts... Dale

May 14, 2012

Re: [Pharo-project] Semantic Versioning

by Dale Henrichs

Francois, Regarding the mutability of Metacello configurations ... you are right that it is tempting, but one should never modify a version that has been marked as #released ... it is a convention. One of the appeals of git/github is that a git commit is immutable so all of the artifacts in a commit are guaranteed. Even with git, tags (the only real place to use a version string) are not immutable ... by convention you don't change tags. In the end there is no replacement for discipline... Dale ----- Original Message ----- | From: "Francois Stephany" <tulipe.moutarde(a)gmail.com> | To: pharo-project(a)lists.gforge.inria.fr | Sent: Monday, May 14, 2012 9:02:25 AM | Subject: Re: [Pharo-project] Semantic Versioning | | | > So if I fix | > a bug, and now Pharo 1.3 will have to load package.pharo13.3 and | > Squeak | > package.squeak43.5, I would declare 1.3.1 in my config with the new | > packages. Does that sound right? | | Yep, sounds right. | What if you only need the bug fix in the Pharo version and not the | Squeak one? The package becomes 1.3.1 in Squeak but is identical to | 1.3.0. No big deal I guess... | | My main concern at the moment is that a MetacelloConfig is always | modifiable. It is tempting to fix a version that is already | distributed | and thus confuse everyone. | | A release should maybe be a complete new entity (and not editable) | hosted somewhere else than in the code repository. The Fuel gsoc | would | probably help a lot for that. We can maybe imagine something Ã la | Ruby gems? | |

May 14, 2012

Re: [Pharo-project] Semantic Versioning

by Sean P. DeNigris

fstephany wrote > > What if you only need the bug fix in the Pharo version and not the > Squeak one? The package becomes 1.3.1 in Squeak but is identical to > 1.3.0. No big deal I guess... > Well, we're versioning the *project* i.e. the config, not the package, so I don't think there's a conflict. fstephany wrote > > My main concern at the moment is that a MetacelloConfig is always > modifiable. It is tempting to fix a version that is already distributed > and thus confuse everyone. > Yes, this would be a big problem and violates the spirit of Metacello. Just as bad is the fact that Metacello configs are copied all over the place. Is the ConfigurationOf that I download from SqS/projectName the same one as SqS/MetacelloRepository the same as SqS/WhateverForPharo1.4... IMO it's absolutely essential to have one master, and read-only copies everywhere elsewhere. fstephany wrote > > We can maybe imagine something Ã la Ruby gems? > That would be awesome!!! Metacello is sooo young and we've already had so much progress. I'm sure that won't be far off... -- View this message in context: http://forum.world.st/Semantic-Versioning-tp4630055p4630164.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 14, 2012

Re: [Pharo-project] Notify progress with Announcements instead of Exceptions

by Sean P. DeNigris

Sean P. DeNigris wrote > > [:barValArg | | barVal return newBarSize | > barVal := barValArg. > return := nil. > ... > "new fun stuff here" > barVal == #current ifTrue: [ return := barSize ]. > barVal == #label ifTrue:[ return := (labels at: slot) contents ]. > barVal == #setMax ifTrue: [ return := maxValue. maxValue := minValue ]. > barVal == #setMin ifTrue: [ return := minValue. minValue := maxValue ]. > barVal == #increment ifTrue: [return := barVal := barSize + 1]. > barVal == #decrement ifTrue: [ return := barVal := barSize - 1]. > (barVal isString and: [barVal isSymbol not]) ifTrue: [ > (labels at: slot) contents: barVal. > barVal := #refresh]. > barVal == #refresh ifTrue: [self currentWorld displayWorld. return := > true]. > ... > return] > I think we should consider this alternate Class implementation. A block with its own custom method lookup mechanism ;-) -- View this message in context: http://forum.world.st/Notify-progress-with-Announcements-instead-of-Excepti… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 14, 2012

Re: [Pharo-project] Semantic Versioning

by Francois Stephany

> So if I fix > a bug, and now Pharo 1.3 will have to load package.pharo13.3 and Squeak > package.squeak43.5, I would declare 1.3.1 in my config with the new > packages. Does that sound right? Yep, sounds right. What if you only need the bug fix in the Pharo version and not the Squeak one? The package becomes 1.3.1 in Squeak but is identical to 1.3.0. No big deal I guess... My main concern at the moment is that a MetacelloConfig is always modifiable. It is tempting to fix a version that is already distributed and thus confuse everyone. A release should maybe be a complete new entity (and not editable) hosted somewhere else than in the code repository. The Fuel gsoc would probably help a lot for that. We can maybe imagine something Ã la Ruby gems?

May 14, 2012