[Cuis-dev] [Important] Additional packages for Stable (LTS) releases (was Re: Re : Re: Beta for Cuis 7.0 stable, Rolling Release is 7.1)

[Juan Vuletich]

Hi Folks,

On 5/23/2024 4:31 PM, Hilaire Fernandes via Cuis-dev wrote:
>
> Le 22/05/2024 à 19:28, ken.dickey at whidbey.com a écrit :
>> Well, Cuis7-0 is supposed to be Stable and Cuis-Smalltalk-Dev, 
>> Current, will keep changing.
>>
>> My thought was that DrGeo-Stable would be released with Cuis-Stable 
>> and DrGeo-Current (unreleased) would be done against Cuis-Current.
> My initial idea was to stick to a Cuis-stable to produce DrGeo 
> release, but it was unpractical.

The releases of DrGeo you give to your users should ideally be made with 
the latest Cuis Stable release at that time. That makes sense and 
everybody agrees with that. The point Ken is making is that it also 
makes sense to keep developing DrGeo new features and enhancements not 
on the stable release, but on the current Cuis rolling release. This 
will keep DrGeo updated as Cuis evolves, and will also let you take 
advantage of new Cuis enhancements. Of course, Hilaire, it is your call. 
Ken is making a suggestion, and it is a good one in my view.

>>
>> If you are making a Release of DrGeo against Cuis-Current, I would 
>> expect you to have to copy/freeze any packages you use with the DrGeo 
>> release, including the Cuis-Current base.
>
> Not really, I just use the latest packages I need, which are supposed 
> to be more or less compatible with current.

Here, I agree with you Hilaire. If you're working on Cuis rolling 
release, you'd use the latest of everything. Cuis, and 3rd party packages.

>
> The difficulty is when using Cuis-Stable to develop DrGeo or any 
> complex application, it needs versions of third party packages known 
> to work with Cuis-Stable, and those may not be latest version
>
> => A common policy may be useful, otherwise CuisStable will be useful 
> only for applications not depending on third party packages (the one 
> outside the Cuis-Smalltalk organisation that Juan capture).

Of course. All this thread is about finding a good way to do that.

>>
>> I have not looked, but I am presuming you have a DrGeo Release 
>> (all-in-one?) which is expected to be stable for your users.
>
> No all-in one, it is confusing for users. But yes DrGeo user are 
> supposed to use the release. Some advanced user, pull the repos and 
> play with DrGeo on the edge. For these user, and me, whatever I use 
> cuis-stable or cuis-current, the right version of the dependency 
> packages should easily come along.
>
>>
>> To help more than hurt, I probably need to know more of your DrGeo 
>> Release packaging strategy.

Thanks,

-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich