chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] Re: repository branching


From: Matthew Welland
Subject: Re: [Chicken-hackers] Re: repository branching
Date: Sat, 23 Feb 2008 06:58:07 -0700
User-agent: KMail/1.9.6 (enterprise 0.20070907.709405)

On Saturday 23 February 2008 05:16:14 am Alejandro Forero Cuervo wrote:

> > That's not important. Consider the older releases obsolete. Forget
> > about them.
>
> I would rather not.  I would like to continue providing updates for my
> eggs for older releases *in those cases in which it costs me nothing
> to do so* (that is, in 100% of my 22 eggs).  Since it costs me nothing
> to continue supporting them, I don't see a reason to force users of my
> eggs to upgrade whenever they want access to new functionality (or, to
> put it another way, I don't want to have to update 4 chicken
> installations the next time I release one of the eggs in which my
> software depends).

I want to throw in my $0.02 on this. I think it is important.

As an end user I don't want new features showing up in old eggs. The old egg 
should be exactly as it was when it was released baring perhaps serious bug 
fixes. The old releases are kept around to keep things *stable* for those 
who cannot change for some reason. Now, it should also be possible to 
install any version of an egg on an old version of chicken with a little 
manual intervention. 

In short - don't expend resources making it easy for people to avoid 
upgrading for long periods of time. But do make it easy for someone to get 
back to a previous state in the chicken world.

One more time as an example: 

- Support the poor bloke who needs to quickly deploy an old crufty bit of 
chicken code that built fine two years ago with chicken. He just wants to 
get it built and running and deployed. It doesn't build with the current 
release. Fine. Get the version of chicken from two years ago build and 
release and then move on. NB// the new system addresses this.

- Don't support someone who wants a feature only found in a new version of 
an egg but for whatever reason can't be bothered to upgrade chicken to get 
it. If you need a new feature you are probably in active development mode 
and can deal with the minor delay in moving to the latest chicken.

Now, about the svn release mechanism...

I wasn't able to find in my email the spec for the new release mechanism but 
I hope the following is accurate:

For the common case, egg developers work on the "head" of their egg code and 
never have to deal with the release mechanism at all. If an egg developer 
*wants* to support the old releases of their eggs they need to do an svn co 
of the old version(s) and deal with a little additional svn burdern.

Matt
--




reply via email to

[Prev in Thread] Current Thread [Next in Thread]