Re: So... this is 4.2?

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent
thread

Re: So... this is 4.2?
by ac on Saturday 03/May/2008, @13:12

you realy have to stop spreading fud....

there is no standard "textbook" way of doing softwaredevelopment. and in the days of dvcses your proposal is long deprecated. if kde wants to use more branching, every new feature should get its own branch, which are merged back to trunk when the new code is stable.

though svn isn't meant to be used like that, so heavily using branches in the main repository is actually no option for kde today.

having more than one main-branch like you propose is a maintenence nightmare for big projects...

but thats not the point. kde already does what you want. its called the feature freeze, and like its name suggests, it doesn't allow new features in the repository when a new release is stabilizing.

Related Links

·   Articles on Developer
·   Also by ac
·   Contact author

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: So... this is 4.2?
by JRT on Tuesday 06/May/2008, @06:57

It is not my intent to spread FUD. I am asking for higher quality. Or, stating that higher stability in releases is needed.

You are correct that there is NOT one standard textbook method of doing software development (one dead Straw Man) -- there are many. However, there objectives which they must meet.

I do not see that the idea is long deprecated since other OSS projects use other models which I believe are better.

Next Straw Man. I made no suggestion about using many multiple branches. That is something which you brought up.

I am suggesting EITHER earlier branching for release branches or (not my first choice) having a stable and an unstable release branch. Such an extra branch might actually make thing easier. Do you have a citation that would support your unsupported statement (is this just your opinion) that having another branch would be "a maintenence [sic] nightmare for big projects". Quite the opposite is, in general, true.

Small projects can use most any development method. It is large projects that need something more structured. The KDE project has grown and it now needs more structured methods. The proof of this is what I stated: lack of stability and regressions along with new features that were in releases before they were ready for prime time.

You seem to have missed what I said about a "feature freeze". I said that pre-alpha branching can replace a feature freeze. Obviously, I don't think that the feature freeze accomplishes what I think is necessary or I wouldn't have suggested that change was needed. Some of the new features added to KDE 3.x.y didn't stabilize enough before they were released.

So, your argument reduces to 'no you are wrong'. Do you have any suggestions? Or, are you just going to use rhetoric and logical fallacies to defend the status quo?

[ Reply To This | View ]

The Fine Print: The previous comments are owned by whomever posted them.
( Reply )


		"I just wanted to be certain that the code was unmaintainable." -- Charles Samuels
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.