Christian Edward Gruber wrote:
> Dear Anders,
>>-----Original Message-----
>>From: Anders Peterson [mailto:anders_peterso..ptimatika.se]
>>If there are 10 bug fix releases before a new feature release we'll just
>>have to call it 1.1.0 - we should try to avoid this. I really think we
>>should limit the number of releases. Users who absolutely want the
>>latest features or bug fixes should build from source.
>
> I couldn't disagree with you more. For organizations that deploy the
> package to multiple computers, especially busy organizations, going
> through a build, and then deploying rather than grabbing an update from
> eclipse central is a much more difficult task. I think regular patching
> is quite reasonable, especially since I can't see there being a limit
> preventing a 1.1.10, 1.1.11, etc.
>
> I know many developers are quite cavalier about build vs. package and
> see the latter as laziness on the part of some user, but actually going
> through a package and deploy to an auto-update system is a level of
> quality control that behooves any project. In my tracking of the
> OpenBSD ports process, on of the watershed moments in the quality of the
> ports system was when all installations, even directly when building
> from source through the build system, went through the packaging process
> and installed from a binary package. It required that all the ports had
> the minimum sanity check of satisfying the packaging system's
> constraints. WoLips would benefit from this as well, I believe.
Perhaps your interpretation of "frequent" is the same as mine of "limited"?
The way I see it there are 3 kinds of WOLips "users":
1) Developers (probably working in the Eclipse PDE)
2) Testers and early adopters
3) Ordinary users
I do not think the ordinary users should have to build from source -
absolutely not. I do think that testers and early adopters could build
from source. Especially when/if it could save us the trouble of making a
release. (I assume this is where we disagree?)
Do you want to release versions, through the Eclipse Update Manager,
that are really only intended for developers, testers and early adopters?
Releasing a new version is (should be) telling the ordinary users that
there is a "better" version - it either has new features or fixed bugs,
and it has been tested.
That busy organisation should not use beta software. They should stick
to released versions.
>>The main reason to have branches would be to allow making a bug fix
>>release although work on the next feature release has already begun.
>>
>>As I understand it branches can be cretaed as (when) needed. If we
>>create a version for a release, we can then branch on that version if
>>and when it becomes necessary.
>
> Agreed. Upon producing a release candidate you tag a version, and when
> you decide that a given candidate is final, you branch from that tag,
> and all patches are then controlled on that branch. Any new
> development, or patches not intended to be rolled into a patched version
> of the previous release go on the HEAD.
We seem to have the same idea on how this should work. Anyone with
different ideas?
/Anders
This archive was generated by hypermail 2.0.0 : Fri Apr 04 2003 - 11:13:51 EST