Cuis base image reduced by 25%!
Locked
Cuis base image reduced by 25%!
 
|
Hi Folks,
A few days ago I started playing with the idea of extracting non-essential functionality into .pck.st files. The result is that I could reduce Cuis by about 25%. Now it is below 500 classes and below 100kLOC :) . The new packages are: - Compression - Graphic-Files-Additional (only png and tiff, as bmp and jpg are in the base image) - Sound - Theme-Themes (Only the default class Theme is included in the base image) - Network-Kernel - LinearAlgebra - Test If you update your image, all this code will be removed. If you download the updated image, it is no longer there. The packages themselves are also available at github, together with a txt file with a possible load order. I hope you'll find this more convenient when contributing code. There are several open questions, and I ask for your opinions and thoughts. 1) The "official" Cuis image can have none/some/all of these preloaded. We need to allow for clean unload of packages, but if there are no overrides, I think it is not a big deal. I'm not sure what's best. Maybe all these packages (and maybe others) should be preloaded by default. 2) I'm starting to believe that it is best to have those packages that are kept up to date in the same git repo as the base image. This will make it very easy to know what is the proper snapshot of some package to be used with a particular Cuis update level. Besides, it makes sense to have a Cuis-Smalltalk organization. Therefore I created https://github.com/Cuis-Smalltalk , although I haven't saved anything there yet. I'd like to discuss with you the repositories to keep and their structure. I think that we might store there those packages that are preloaded, and those that are well maintained and actually used. But on the other hand, folks wanting to have better control of their code might prefer to host them in their own repositories... After all this, https://github.com/jvuletich/Cuis should be deleted or marked as historic. BTW, there are a few other fixes and enhancements in this last batch of updates. #reduceCuis now produces a 3.6Mb image with less than 80kLOC. Another tweak was to no longer kill the active changeset on image save. I hope this fits people who usually save the dev image at the end of the day. Let's discuss and think of better ways to manage the Cuis codebase. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Cuis base image reduced by 25%!
|
|
Great news! Before I forgot to mention... I'm started to use npm (from node.js, node package manager) to manage a project dependencies, in AjTalk, Mass, AjGenesis, RunIt.
That is: you can publish a directory to npm, with .st or whatever (I asked in npm mailing list and it's OK, they accept not node-related package) Each publish package has a .json describing its dependencies (including versions).
A project can have a .json describing its dependencies too. So, any Cuis/AjTalk/whatever project can have a package.json at project directory, and the only thing to do is:
npm install and voila! In AjTalk, I adopted the module pattern, so if a module A needs B@0.1.0, it can be loaded, and if module C needs B@0.2.0, then the other version is loaded. See npm/node for more detailed explanation. Some ideas at:
Angel "Java" Lopez
@ajlopez gh:ajlopez On Wed, Jun 26, 2013 at 12:37 AM, Juan Vuletich <[hidden email]> wrote: Hi Folks, _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Juan Vuletich-4
Hi Juan,
This is great! I very much like that direction as you know. ;-) See more inline. Am 26.06.2013 um 05:37 schrieb Juan Vuletich: > If you update your image, all this code will be removed. By "update your image" you mean loading the ChangeSets individually, right? There is no update command yet, right? > If you download the updated image, it is no longer there. The packages themselves are also available at github, together with a txt file with a possible load order. I hope you'll find this more convenient when contributing code. I think this makes contributing code much easier – for the extracted *.pck.st files. ;-) We can use pull requests for those packages with all the GitHub goodness which comes with them. > There are several open questions, and I ask for your opinions and thoughts. > > 1) The "official" Cuis image can have none/some/all of these preloaded. This is a very good question. If I had to choose between "none" or "all" for the "official" image I would choose "all". You should definitely do development of Cuis in an image with all packages loaded. Otherwise, the external packages will break very fast. Do you agree? For the same reason I would encourage all developers to do developement in images with all packages loaded. > We need to allow for clean unload of packages, but if there are no overrides, I think it is not a big deal. If you can figure out the right unload order. > I'm not sure what's best. Maybe all these packages (and maybe others) should be preloaded by default. Of course, it would be best to provide both, "all" and "none". However, I would only do this by a fully automated build process. Otherwise it gets too much work fast. travis.ci anyone? > 2) I'm starting to believe that it is best to have those packages that are kept up to date in the same git repo as the base image. This will make it very easy to know what is the proper snapshot of some package to be used with a particular Cuis update level. I agree. For packages which are meant to be supported together with Cuis I believe this is the best approach. > Besides, it makes sense to have a Cuis-Smalltalk organization. Therefore I created https://github.com/Cuis-Smalltalk , although I haven't saved anything there yet. I'd like to discuss with you the repositories to keep and their structure. I think that we might store there those packages that are preloaded, and those that are well maintained and actually used. But on the other hand, folks wanting to have better control of their code might prefer to host them in their own repositories... > > After all this, https://github.com/jvuletich/Cuis should be deleted or marked as historic. > > BTW, there are a few other fixes and enhancements in this last batch of updates. #reduceCuis now produces a 3.6Mb image with less than 80kLOC. Another tweak was to no longer kill the active changeset on image save. I hope this fits people who usually save the dev image at the end of the day. > > Let's discuss and think of better ways to manage the Cuis codebase. Yes, let's! Cheers, Bernhard _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Cuis base image reduced by 25%!
|
|
In reply to this post by Juan Vuletich-4
Inline
On Tue, Jun 25, 2013 at 8:37 PM, Juan Vuletich <[hidden email]> wrote: Hi Folks, I had a feeling this would happen. Not bad. How are sounds represented in the source, are they base-64 encoded? It might be good to have the actual sounds in a content pack, partly because I've wanted to replace them for some time, and just got ahold of a digital audio workstation (weeeeeeeee!)
If you update your image, all this code will be removed. If you download the updated image, it is no longer there. The packages themselves are also available at github, together with a txt file with a possible load order. I hope you'll find this more convenient when contributing code. I'd put the tests back in for our development image. They don't necessarily need to live in "release" images though. If we're still thinking of making such a distinction. I think it's been talked about. Not having them resident without going through an extra step will probably mean (path of least resistance) almost no one will run them. I should get CI working one of these days and take some of the burden of running tests off of human shoulders.
There are several open questions, and I ask for your opinions and thoughts. I like the full image + minimal dev image with tests idea. But we should have CI before we start juggling two images so we know when loading a package or not loading a package causes problems IMHO.
2) I'm starting to believe that it is best to have those packages that are kept up to date in the same git repo as the base image. This will make it very easy to know what is the proper snapshot of some package to be used with a particular Cuis update level. Besides, it makes sense to have a Cuis-Smalltalk organization. Therefore I created https://github.com/Cuis-Smalltalk , although I haven't saved anything there yet. I'd like to discuss with you the repositories to keep and their structure. I think that we might store there those packages that are preloaded, and those that are well maintained and actually used. But on the other hand, folks wanting to have better control of their code might prefer to host them in their own repositories... Yes, definitely. After all this, https://github.com/jvuletich/Cuis should be deleted or marked as historic. Sweet! Let's discuss and think of better ways to manage the Cuis codebase. Casey Ransberger _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Cuis base image reduced by 25%!
|
|
In reply to this post by bpi
Hi Bernhard,
(inline and abridged) On 26/06/2013 03:09 p.m., Bernhard Pieber wrote: > Hi Juan, > > This is great! I very much like that direction as you know. ;-) > > See more inline. > > Am 26.06.2013 um 05:37 schrieb Juan Vuletich: >> If you update your image, all this code will be removed. > By "update your image" you mean loading the ChangeSets individually, right? There is no update command yet, right? Right and right. There is no "update command" yet. We'd add it sometime. >> If you download the updated image, it is no longer there. The packages themselves are also available at github, together with a txt file with a possible load order. I hope you'll find this more convenient when contributing code. > I think this makes contributing code much easier – for the extracted *.pck.st files. ;-) We can use pull requests for those packages with all the GitHub goodness which comes with them. Yes! I'd love to see pull requests used. >> There are several open questions, and I ask for your opinions and thoughts. >> >> 1) The "official" Cuis image can have none/some/all of these preloaded. > This is a very good question. If I had to choose between "none" or "all" for the "official" image I would choose "all". You should definitely do development of Cuis in an image with all packages loaded. Otherwise, the external packages will break very fast. Do you agree? Yes, indeed. > For the same reason I would encourage all developers to do developement in images with all packages loaded. Agreed. The image with packages unloaded would be better, for example, for people learning about the system, or with specific needs. >> We need to allow for clean unload of packages, but if there are no overrides, I think it is not a big deal. > If you can figure out the right unload order. Ken's suggestion, "Features" should help with that. >> I'm not sure what's best. Maybe all these packages (and maybe others) should be preloaded by default. > Of course, it would be best to provide both, "all" and "none". However, I would only do this by a fully automated build process. Otherwise it gets too much work fast. travis.ci anyone? Well, maybe there's no need to provide the "none" image on each update, but only on "official version release", if this concept still makes sense... Thinking aloud now. I think that the Cuis-Smalltalk GitHub organization could have 3 repositories: Cuis-Smalltalk/Stable : Committed just a few times a year. Contains only reasonable tested image(with packages), image(without any packages), packages. Each commit is a Cuis version.revision number. All packages should load and run reasonably well. If we're freezing a release, and some package is not updated, and is incompatible with the release, it is removed from here (i.e. it is "not supported" for this release). Cuis-Smalltalk/Development : Contains more frequent commits of image(with selected / all packages preloaded), supported packages (to ease diffing in the web browser), and update stream (numbered change sets). Might occasionally be broken, or include incomplete stuff. For people who want the latest, and can cope with this. For example, package developers, and people contributing code to the base image. Packages are only removed from here when abandoned (i.e. they are broken/incompatible, and nobody is working on fixing them anymore). Cuis-Smalltalk/Historic : One zip file for each release Does this make sense? > ... > Cheers, > Bernhard Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Cuis base image reduced by 25%!
|
|
In reply to this post by Casey Ransberger-2
Hi Casey,
On 27/06/2013 05:02 p.m., Casey Ransberger wrote:
Mhhh. I think you have something there. We'd merge packages and content pack in some way, to let package include media, with the advantages of content pack...
Yes. Please check a message I just sent to this thread. I think the best is doing the minimal image only on official releases, and do dev on a full image, as Bernhard suggests.
:) Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Cuis base image reduced by 25%!
|
|
In reply to this post by Juan Vuletich-4
On 29 June 2013 21:45, Juan Vuletich <[hidden email]> wrote:
> Hi Bernhard, > > (inline and abridged) > > On 26/06/2013 03:09 p.m., Bernhard Pieber wrote: >> >> Hi Juan, >> >> This is great! I very much like that direction as you know. ;-) >> >> See more inline. >> >> Am 26.06.2013 um 05:37 schrieb Juan Vuletich: >>> >>> If you update your image, all this code will be removed. >> >> By "update your image" you mean loading the ChangeSets individually, >> right? There is no update command yet, right? > > > Right and right. There is no "update command" yet. We'd add it sometime. > >>> If you download the updated image, it is no longer there. The packages >>> themselves are also available at github, together with a txt file with a >>> possible load order. I hope you'll find this more convenient when >>> contributing code. >> >> I think this makes contributing code much easier – for the extracted >> *.pck.st files. ;-) We can use pull requests for those packages with all the >> GitHub goodness which comes with them. > > > Yes! I'd love to see pull requests used. > >>> There are several open questions, and I ask for your opinions and >>> thoughts. >>> >>> 1) The "official" Cuis image can have none/some/all of these preloaded. >> >> This is a very good question. If I had to choose between "none" or "all" >> for the "official" image I would choose "all". You should definitely do >> development of Cuis in an image with all packages loaded. Otherwise, the >> external packages will break very fast. Do you agree? > > > Yes, indeed. > >> For the same reason I would encourage all developers to do developement in >> images with all packages loaded. > > > Agreed. The image with packages unloaded would be better, for example, for > people learning about the system, or with specific needs. > >>> We need to allow for clean unload of packages, but if there are no >>> overrides, I think it is not a big deal. >> >> If you can figure out the right unload order. > > > Ken's suggestion, "Features" should help with that. > >>> I'm not sure what's best. Maybe all these packages (and maybe others) >>> should be preloaded by default. >> >> Of course, it would be best to provide both, "all" and "none". However, I >> would only do this by a fully automated build process. Otherwise it gets too >> much work fast. travis.ci anyone? > > > Well, maybe there's no need to provide the "none" image on each update, but > only on "official version release", if this concept still makes sense... > Thinking aloud now. I think that the Cuis-Smalltalk GitHub organization > could have 3 repositories: > > Cuis-Smalltalk/Stable : Committed just a few times a year. Contains only > reasonable tested image(with packages), image(without any packages), > packages. Each commit is a Cuis version.revision number. All packages should > load and run reasonably well. If we're freezing a release, and some package > is not updated, and is incompatible with the release, it is removed from > here (i.e. it is "not supported" for this release). > > Cuis-Smalltalk/Development : Contains more frequent commits of > image(with selected / all packages preloaded), supported packages (to ease > diffing in the web browser), and update stream (numbered change sets). Might > occasionally be broken, or include incomplete stuff. For people who want the > latest, and can cope with this. For example, package developers, and people > contributing code to the base image. Packages are only removed from here > when abandoned (i.e. they are broken/incompatible, and nobody is working on > fixing them anymore). > > Cuis-Smalltalk/Historic : One zip file for each release Surely the natural approach to this in GitHub would be branches? "master" branch is your Stable, "devel" branch is your Development, and you fork off different branches for each release. frank > Does this make sense? > >> ... >> Cheers, >> Bernhard > > > Cheers, > Juan Vuletich > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Juan Vuletich-4
Juan,
On Jun 25, 2013, at 11:37 PM, Juan Vuletich wrote: > Hi Folks, > > A few days ago I started playing with the idea of extracting non-essential functionality into .pck.st files. The result is that I could reduce Cuis by about 25%. Now it is below 500 classes and below 100kLOC :) . The new packages are: > > - Compression > - Graphic-Files-Additional (only png and tiff, as bmp and jpg are in the base image) > - Sound > - Theme-Themes (Only the default class Theme is included in the base image) > - Network-Kernel > - LinearAlgebra > - Test > That sounds fantastic! > If you update your image, all this code will be removed. If you download the updated image, it is no longer there. The packages themselves are also available at github, together with a txt file with a possible load order. I hope you'll find this more convenient when contributing code. > > There are several open questions, and I ask for your opinions and thoughts. > > 1) The "official" Cuis image can have none/some/all of these preloaded. We need to allow for clean unload of packages, but if there are no overrides, I think it is not a big deal. I'm not sure what's best. Maybe all these packages (and maybe others) should be preloaded by default. > While the purist in me would probably say have nothing preloaded, as a practical matter this might make it more difficult for newbies to get going with Cuis and even experienced users who don't want or care about an absolutely minimal image. As long as it's easy to unload packages, it might make sense to keep them preloaded and let those who are interested (me! me! :-) unload what they don't need. I'd also love to see Cuis move towards Casey's content pack idea with a twist: why restrict it to just sounds? Why not have all binary assets (sound, images, whatever) broken out into content packs as appropriate? Longer term, you could also go a step further and rather than base64 encoding them, just load them from the binary .wav (or whatever native file) instead of baking into the source. There would seem to be some serious advantages to that extra step but it would also create some more work so I'm just throwing it out there as longer-term food for thought. > 2) I'm starting to believe that it is best to have those packages that are kept up to date in the same git repo as the base image. This will make it very easy to know what is the proper snapshot of some package to be used with a particular Cuis update level. Besides, it makes sense to have a Cuis-Smalltalk organization. Therefore I created https://github.com/Cuis-Smalltalk , although I haven't saved anything there yet. I'd like to discuss with you the repositories to keep and their structure. I think that we might store there those packages that are preloaded, and those that are well maintained and actually used. But on the other hand, folks wanting to have better control of their code might prefer to host them in their own repositories... Just to keep it simple, a single repo for the Cuis 'core' (whatever that ends up being defined as) seems to make sense, regardless of what package things gets put into. Even if there end up being different maintainers of the various modules, Git makes that pretty easy to deal with without requiring multiple repos. > > After all this, https://github.com/jvuletich/Cuis should be deleted or marked as historic. > > BTW, there are a few other fixes and enhancements in this last batch of updates. #reduceCuis now produces a 3.6Mb image with less than 80kLOC. Another tweak was to no longer kill the active changeset on image save. I hope this fits people who usually save the dev image at the end of the day. > > Let's discuss and think of better ways to manage the Cuis codebase. Related to your multi-repo suggestion, I'm with Frank in thinking that dev/stable probably belong in the same repo as different branches as that's how most other projects handle it. Historic seems to make more sense as a separate repo as that would just be a point in time snapshot of an image built from the main repo and would potentially appeal to a different subset of users. > > Cheers, > Juan Vuletich > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org Thanks, Phil _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Cuis base image reduced by 25%!
|
|
In reply to this post by Juan Vuletich-4
On 6/26/13, Juan Vuletich <[hidden email]> wrote:
> Hi Folks, > > A few days ago I started playing with the idea of extracting > non-essential functionality into .pck.st files. The result is that I > could reduce Cuis by about 25%. Now it is below 500 classes and below > 100kLOC :) . Congratulations. Amazing! The new packages are: > > - Compression > - Graphic-Files-Additional (only png and tiff, as bmp and jpg are in the > base image) > - Sound > - Theme-Themes (Only the default class Theme is included in the base image) > - Network-Kernel > - LinearAlgebra > - Test > > If you update your image, all this code will be removed. If you download > the updated image, it is no longer there. The packages themselves are > also available at github, together with a txt file with a possible load > order. I hope you'll find this more convenient when contributing code. > > There are several open questions, and I ask for your opinions and thoughts. > > 1) The "official" Cuis image can have none/some/all of these preloaded. > We need to allow for clean unload of packages, but if there are no > overrides, I think it is not a big deal. I'm not sure what's best. Maybe > all these packages (and maybe others) should be preloaded by default. > > 2) I'm starting to believe that it is best to have those packages that > are kept up to date in the same git repo as the base image. This will > make it very easy to know what is the proper snapshot of some package to > be used with a particular Cuis update level. Besides, it makes sense to > have a Cuis-Smalltalk organization. Therefore I created > https://github.com/Cuis-Smalltalk , although I haven't saved anything > there yet. I'd like to discuss with you the repositories to keep and > their structure. I think that we might store there those packages that > are preloaded, and those that are well maintained and actually used. But > on the other hand, folks wanting to have better control of their code > might prefer to host them in their own repositories... > > After all this, https://github.com/jvuletich/Cuis should be deleted or > marked as historic. > > BTW, there are a few other fixes and enhancements in this last batch of > updates. #reduceCuis now produces a 3.6Mb image with less than 80kLOC. Useful for scripting purposes. --Hannes > Another tweak was to no longer kill the active changeset on image save. > I hope this fits people who usually save the dev image at the end of the > day. > > Let's discuss and think of better ways to manage the Cuis codebase. > > Cheers, > Juan Vuletich > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Cuis base image reduced by 25%!
|
|
In reply to this post by Frank Shearar-3
On 6/29/13, Frank Shearar <[hidden email]> wrote:
> On 29 June 2013 21:45, Juan Vuletich <[hidden email]> wrote: >> Hi Bernhard, >> >> (inline and abridged) >> >> On 26/06/2013 03:09 p.m., Bernhard Pieber wrote: >>> >>> Hi Juan, >>> >>> This is great! I very much like that direction as you know. ;-) >>> >>> See more inline. >>> >>> Am 26.06.2013 um 05:37 schrieb Juan Vuletich: >>>> >>>> If you update your image, all this code will be removed. >>> >>> By "update your image" you mean loading the ChangeSets individually, >>> right? There is no update command yet, right? >> >> >> Right and right. There is no "update command" yet. We'd add it sometime. >> >>>> If you download the updated image, it is no longer there. The packages >>>> themselves are also available at github, together with a txt file with a >>>> possible load order. I hope you'll find this more convenient when >>>> contributing code. >>> >>> I think this makes contributing code much easier – for the extracted >>> *.pck.st files. ;-) We can use pull requests for those packages with all >>> the >>> GitHub goodness which comes with them. >> >> >> Yes! I'd love to see pull requests used. >> >>>> There are several open questions, and I ask for your opinions and >>>> thoughts. >>>> >>>> 1) The "official" Cuis image can have none/some/all of these preloaded. >>> >>> This is a very good question. If I had to choose between "none" or "all" >>> for the "official" image I would choose "all". You should definitely do >>> development of Cuis in an image with all packages loaded. Otherwise, the >>> external packages will break very fast. Do you agree? >> >> >> Yes, indeed. >> >>> For the same reason I would encourage all developers to do developement >>> in >>> images with all packages loaded. >> >> >> Agreed. The image with packages unloaded would be better, for example, for >> people learning about the system, or with specific needs. >> >>>> We need to allow for clean unload of packages, but if there are no >>>> overrides, I think it is not a big deal. >>> >>> If you can figure out the right unload order. >> >> >> Ken's suggestion, "Features" should help with that. >> >>>> I'm not sure what's best. Maybe all these packages (and maybe others) >>>> should be preloaded by default. >>> >>> Of course, it would be best to provide both, "all" and "none". However, I >>> would only do this by a fully automated build process. Otherwise it gets >>> too >>> much work fast. travis.ci anyone? >> >> >> Well, maybe there's no need to provide the "none" image on each update, >> but >> only on "official version release", if this concept still makes sense... >> Thinking aloud now. I think that the Cuis-Smalltalk GitHub organization >> could have 3 repositories: >> >> Cuis-Smalltalk/Stable : Committed just a few times a year. Contains >> only >> reasonable tested image(with packages), image(without any packages), >> packages. Each commit is a Cuis version.revision number. All packages >> should >> load and run reasonably well. If we're freezing a release, and some >> package >> is not updated, and is incompatible with the release, it is removed from >> here (i.e. it is "not supported" for this release). >> >> Cuis-Smalltalk/Development : Contains more frequent commits of >> image(with selected / all packages preloaded), supported packages (to ease >> diffing in the web browser), and update stream (numbered change sets). >> Might >> occasionally be broken, or include incomplete stuff. For people who want >> the >> latest, and can cope with this. For example, package developers, and >> people >> contributing code to the base image. Packages are only removed from here >> when abandoned (i.e. they are broken/incompatible, and nobody is working >> on >> fixing them anymore). >> >> Cuis-Smalltalk/Historic : One zip file for each release > > Surely the natural approach to this in GitHub would be branches? > "master" branch is your Stable, "devel" branch is your Development, > and you fork off different branches for each release. > > frank >> Does this make sense? Yes, I think this is a usful approach some time in the future (2014?). Learning about branches is not all that difficult and Angel had sent some good links to the list in the past (last December or early this year). I think having different branches with will be very useful for people coming up with their own variants of Cuis. For users it then would be a matter of saying 'I want the image of Ken with his Unicode additions'. And that would be a branch of the base image into which he folds in the changes of the base image from time to time. --Hannes >>> ... >>> Cheers, >>> Bernhard >> >> >> Cheers, >> Juan Vuletich >> >> _______________________________________________ >> Cuis mailing list >> [hidden email] >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Cuis base image reduced by 25%!
|
|
In reply to this post by Frank Shearar-3
On 29/06/2013 06:58 p.m., Frank Shearar wrote:
> ... >> Well, maybe there's no need to provide the "none" image on each update, but >> only on "official version release", if this concept still makes sense... >> Thinking aloud now. I think that the Cuis-Smalltalk GitHub organization >> could have 3 repositories: >> >> Cuis-Smalltalk/Stable : Committed just a few times a year. Contains only >> reasonable tested image(with packages), image(without any packages), >> packages. Each commit is a Cuis version.revision number. All packages should >> load and run reasonably well. If we're freezing a release, and some package >> is not updated, and is incompatible with the release, it is removed from >> here (i.e. it is "not supported" for this release). >> >> Cuis-Smalltalk/Development : Contains more frequent commits of >> image(with selected / all packages preloaded), supported packages (to ease >> diffing in the web browser), and update stream (numbered change sets). Might >> occasionally be broken, or include incomplete stuff. For people who want the >> latest, and can cope with this. For example, package developers, and people >> contributing code to the base image. Packages are only removed from here >> when abandoned (i.e. they are broken/incompatible, and nobody is working on >> fixing them anymore). >> >> Cuis-Smalltalk/Historic : One zip file for each release > Surely the natural approach to this in GitHub would be branches? > "master" branch is your Stable, "devel" branch is your Development, > and you fork off different branches for each release. > > frank I guess you're right. I've never used branches, but it sounds like it makes sense to do as you say. Thanks. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
«
Return to Cuis Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |