[sip-comm-dev] The 1.0 release


#1

Hey all,

As you know we've recently spinned our 1.0 branch off of trunk. While
preparing the 1.0 to trunk merges and the 1.0 nightlies we've had a few
off-list discussions (with some of you) on how exactly we should be
handling this release and the following updates that would reflect bug
fixes and other patches.

The initial plan was to go through several release candidates, then
release 1.0.0, then continue with 1.0.x releases until we decide to
discontinue the branch.

The thing is that this way we are adding a lot of release management
overhead without any substantial benefit.

I am therefore suggesting that we handle things the following way:

The first nightly build over the 1.0 branch is to be considered our 1.0
release. This is obviously not going to be THE stable release since
there are still a number of known issues that would get fixed with
subsequent releases. This means that we won't have to announce this
release with all the fanfare typical for a first roll out. All following
commits would then trigger 1.0.x releases. One day, when and if we
manage to fix all pending 1.0 issues we may want to drop a few
announcements here and there notifying the world of our first officially
stable release. If this doesn't happen with 1.0 it would with 2.0.

All auto update mechanisms that we currently support (debian, sparkle,
rpm, and our home grown windows updater) would be working independently
over the two build lines.

We are going to continue maintaining the 1.0 branch and the 1.0.x
releases until we are ready to cast a 2.0 branch and at that point 1.0
would be discontinued. Also at that point the 1.0 updaters are going to
automatically shift to 2.0.

The point of all this is to make sure that branch management is as
simple and as reliable as possible. Does anyone see a problem with this?

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hi Emil, all

Emil Ivov wrote:

The first nightly build over the 1.0 branch is to be considered our 1.0
release. This is obviously not going to be THE stable release since
there are still a number of known issues that would get fixed with
subsequent releases. This means that we won't have to announce this
release with all the fanfare typical for a first roll out. All following
commits would then trigger 1.0.x releases. One day, when and if we
manage to fix all pending 1.0 issues we may want to drop a few
announcements here and there notifying the world of our first officially
stable release. If this doesn't happen with 1.0 it would with 2.0.

Just to make sure I understand correctly:
- 1.0 is the first official release. Though it misses important
features, it has reached a certain level of maturity and can be used on
a daily basis. This is the code present in the 1.0 branch.
- 1.0.x releases will fix remaining known bugs and are build
automatically when a commit hits the 1.0 branch.

We are going to continue maintaining the 1.0 branch and the 1.0.x
releases until we are ready to cast a 2.0 branch and at that point 1.0
would be discontinued. Also at that point the 1.0 updaters are going to
automatically shift to 2.0.

The point of all this is to make sure that branch management is as
simple and as reliable as possible. Does anyone see a problem with this?

If this is not too much hassle for the developers, I think it is better to make few incremental releases (each adding features that we believe are important and are not in 1.0) in the form of 1.x before we go with a 2.0 version. With this approach, we make releases more often, the stable version is then more up-to-date, maintenance of the stable branch is simplified, users can enjoy new features without the need to run a development version, and everybody is happy.

Please let me know your opinion.

Martin

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Agreed. There must be something between nightly builds and outdated
versions. Also quality assurance (albeit boring) is always a worth effort

···

On Wed, Jun 10, 2009 at 07:06, Martin André <martin@mandre.org> wrote:

Hi Emil, all

Emil Ivov wrote:

The first nightly build over the 1.0 branch is to be considered our 1.0
release. This is obviously not going to be THE stable release since
there are still a number of known issues that would get fixed with
subsequent releases. This means that we won't have to announce this
release with all the fanfare typical for a first roll out. All following
commits would then trigger 1.0.x releases. One day, when and if we
manage to fix all pending 1.0 issues we may want to drop a few
announcements here and there notifying the world of our first officially
stable release. If this doesn't happen with 1.0 it would with 2.0.

Just to make sure I understand correctly:
- 1.0 is the first official release. Though it misses important
features, it has reached a certain level of maturity and can be used on
a daily basis. This is the code present in the 1.0 branch.
- 1.0.x releases will fix remaining known bugs and are build
automatically when a commit hits the 1.0 branch.

We are going to continue maintaining the 1.0 branch and the 1.0.x

releases until we are ready to cast a 2.0 branch and at that point 1.0
would be discontinued. Also at that point the 1.0 updaters are going to
automatically shift to 2.0.

The point of all this is to make sure that branch management is as
simple and as reliable as possible. Does anyone see a problem with this?

If this is not too much hassle for the developers, I think it is better to
make few incremental releases (each adding features that we believe are
important and are not in 1.0) in the form of 1.x before we go with a 2.0
version. With this approach, we make releases more often, the stable version
is then more up-to-date, maintenance of the stable branch is simplified,
users can enjoy new features without the need to run a development version,
and everybody is happy.

Please let me know your opinion.

Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hey Martin, all,

Martin André wrote:

Just to make sure I understand correctly:
- 1.0 is the first official release. Though it misses important
features, it has reached a certain level of maturity and can be used on
a daily basis. This is the code present in the 1.0 branch.

Yes.

- 1.0.x releases will fix remaining known bugs and are build
automatically when a commit hits the 1.0 branch.

Yes.

We are going to continue maintaining the 1.0 branch and the 1.0.x
releases until we are ready to cast a 2.0 branch and at that point 1.0
would be discontinued. Also at that point the 1.0 updaters are going to
automatically shift to 2.0.

The point of all this is to make sure that branch management is as
simple and as reliable as possible. Does anyone see a problem with this?

If this is not too much hassle for the developers, I think it is better
to make few incremental releases (each adding features that we believe
are important and are not in 1.0) in the form of 1.x before we go with a
2.0 version. With this approach, we make releases more often, the stable
version is then more up-to-date, maintenance of the stable branch is
simplified, users can enjoy new features without the need to run a
development version, and everybody is happy.

I've been discussing this with others during the last few days and most
seem to agree with the above. (There was also a reply to your mail in
this direction). Therefore we'll soon remove the 2.0 milestone in the
tracker and the roadmap and distribute it over a series of 1.x milestones.

Hope this satisfies everyone.

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net