Subject: CVS migo: * changed version from 2.4.0.1 to 2.4.1

From: FVWM CVS <[email-masked]>
Date: Thu, 05 Jul 2001 19:19:11 -0500

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	migo	01/07/05 19:19:11

Modified files:
	.              : ChangeLog configure.in acinclude.m4 

Log message:
* changed version from 2.4.0.1 to 2.4.1
* hopefully fixed the problem when using autoconf-2.50, originally bug #728
* applied a patch that adds gtk include dirs to gnome include dirs, bug #733

--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 9 Jul 2001 10:37:58 +0200

> * changed version from 2.4.0.1 to 2.4.1

I wonder how we should number our releases at the moment.  We need
some way to have betas with a leading 2.4... since we can't expect
to make a Xinerama release without any betas in between.

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 10 Jul 2001 00:24:06 +0000

> to make a Xinerama release without any betas in between.

Well, there are several possible choices:

  * use 2.4.0.1 (is this understandable that this is beta?)
  * use 2.4.1 for beta (not much different from the previous)
  * use 2.4.1-0.20010920 or 2.4.1-beta1 (I would stick to numeric x.y.z)
  * use temporary names 2.5.x for betas, then return to 2.4.1

We may also fork a branch, do 2.5.x betas and then merge to 2.4.1.
But if the plan now is to do stable 2.4.1, forking is not really needed.

So my vote is to change to 2.5.0 with or without fork accordingly to the
needs, then release next stable 2.4.x, but never 2.6.x.

Probably the real incompatible fork may be done in 2.9.x later.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 15 Jul 2001 14:38:56 +0200

> But if the plan now is to do stable 2.4.1, forking is not really needed.

Since we won't work in parallel on multiple branches there is no
need to create one.  I vote for the "2.4.1-betaX" approach.

> needs, then release next stable 2.4.x, but never 2.6.x.

I agree with the naming schene (2.4/2.5, no 2.6), but a sequence
2.5.0, 2.5.1, 2.4.1 would be confusing.

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 18 Jul 2001 06:56:34 +0200

> 2.5.0, 2.5.1, 2.4.1 would be confusing.

All these depends on what we want to do.

At the present time only "bugs fix" work is released on 2.4.1 and
this seems to me really reasonable: we may want to release 2.4.1
in a few weak without going into a feature-freeze/lot of testing
procedure as some bugs in 2.4.0 are in some sense serious
(libstroke-0.5, FvwmIconMan exiting, compilation failure on some
(old) system).

But we want also to add new features to 2.4.x: at least Xinerama
support and maybe fvwm-ewmh merging. I think, as Dan suggest in an
other thread, that we should open a new branch for these. Here one
reason for this:
Say that we release 2.4.1 in a few weeks as a bug fix release, then
we begin to add new features to the 2.4 branch with version 2.4.2.
Then if we found a serious bug in 2.4.1 we will have some problems
to release 2.4.2 at once (since 2.4.2 will be beta).

So I think that if we want to add new feature to 2.4 we need a
new branch: 2.5 (We may even want to release 2.6 at some point).
I do not think that a sequence like 2.5.0, 2.5.1, 2.4.2 would be
confusing: 2.4.2 will only contains back port of new features from
the 2.5 branch (the linux kernel use this method). Moreover, if we
do not want to release 2.6.0 at all and do not want to have a devel
branch without a stable release at the end we can open 2.9 now, do
the work we want to do for 2.4.x in 2.9 and back port it. But I think
that 2.5 is better.

An other advantage of a 2.5 branch is that doing 3.0.0 can take
some years. So at some point it will be may be good to release
2.6 with some important feature from 2.9 but "compatible" with 2.4.

Regards, Olivier

---

From: Dan Espen <[email-masked]>
Date: Thu, 19 Jul 2001 08:41:05 -0400

Olivier Chapuis <[email-masked]> writes:
> in a few weeks without going into a feature-freeze/lot of testing

A week for 2.4.1 seems good.

> to release 2.4.2 at once (since 2.4.2 will be beta).

I suggested opening 2 branches, one for Xinerama, the other for
fvwm-ewmh.

> the work we want to do for 2.4.x in 2.9 and back port it. But I think

I don't think numbering the branch 2.5 is a good, mainly because I don't
think we should start a 2.5 series that will take 2 years to release.

If we name the branches instead of numbering them, we can easily create
merged source trees to test all or some of the branches.  When any one
of the branches becomes stable, it can be merged into 2.4.x and released.

> 2.6 with some important feature from 2.9 but "compatible" with 2.4.

I hope we NEVER create an incompatible release.

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 21 Jul 2001 16:03:36 +0200

> I hope we NEVER create an incompatible release.

If we do make the changes planned for 3.0 - e.g. removing the
TitleStyle, BorderStyle and ButtonStyle commands - 3.0 *will*
be incompatible.  It wouldn't make sense to clean up the syntax
for simplicity and the try to keep compatibility.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 21 Jul 2001 19:24:27 +0000

> of the branches becomes stable, it can be merged into 2.4.x and released.

Do you suggest this for 2.4.x releases or for later ones as well?

So a new named branch should be created for any new feature (or a set of
features). For example, 2.4.2 requires 2 named branches, 3.0 requires at
least 20 named branches accourding to todo-3.0 and mail archives.

What should a developer do? I suppose, have the source trees for all N
branches and install them in N locations. Should we release beta version
for every branch? If not, how the beta branch becomes stable? What should
a user do with all these betas if we do release betas for every branch?

Managing N branches (creating, commiting, merging, installing, running) is
a nightmare. If the same developers and users work on / test all branches,
having more than one beta branch has only disadvantages in my opinion.

Correct me if I miss something. If this works, please describe how.

> I hope we NEVER create an incompatible release.

Well, any software theory suggests for evolving projects to do full or
partial refactoring from time to time. And to break compatibility without
thinking twice if this improves the project. At the end the user benefits
from a better program, even he should learn new things.

We tried hard to keep 2.4 compatible with 2.2, I don't think this should
be necessarily continued to 3.0.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 21 Jul 2001 20:40:23 +0200

> be necessarily continued to 3.0.

I'm not the biggest fan of branches.  The past has shown that we
can manage fvwm with only two branches: the development branch and
the stable branch.  I see no need to break this pattern anytime
soon.  I am dead determined to include Xinerama support into
2.4.1 along with the first bunch of bug fixes.  If we don't make a
religion of our nice new release numbering scheme (2nd digit odd
= development, even = stable) there should not be any problem.
Now that I managed to get my Xinerama setup running again (had a
lot of trouble with mail and X11 in the past few weeks), I am
working hard on that feature.

After that, it's probably best not to start with the disrupting
features.  There is a huge backlog of small enhancements and
fixes, so there is no need to start with the syntax rewrites in
the near future.  Perhaps even a 2.6 release in between may be in
order.

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Sat, 21 Jul 2001 18:44:16 -0400

> Correct me if I miss something. If this works, please describe how.

I agree with the points you raise, but...

If we put stable and unstable things on the same branch, the branch
never becomes stable.

I'm just trying to figure out some way to avoid our last, too long,
release cycle.

I don't think we need a branch for every change, just some subset
of them.

> be necessarily continued to 3.0.

I've still got users using fvwm1 because they couldn't be bothered
converting their .fvwmrc to .fvwm2rc format.

If things have to change, I guess I can't stop it.

I hope whatever changes are made can be handled with a conversion
script.