text_combined: chromatic chromaticwgzorg tuesday 05 august 2008 123550 geoffrey broadwell wrote definitely need multiple longlived branches make explicit reasoning data loss security otherwise critical bugfixes backported one already released versions rereleased immediately thats lot harder dont release branches course branch lazily since releases tagged assume multiple longlived branches wont merge go away thats horrible doubt give morphine five year old falls scrapes knee equivalent releasing software see patching previous release case critical bugfix get habit encouraging users expect updates anything older previous stable release free weve doomed project point releases every month major releases every three months complete utter refusal support users expect install parrot 10 get free support mailing list irc next eight ten years dont set expectations might avoid problem leeches future see perl 5 example maintaining multiple stable branches doesnt work encouraging people upgrade doesnt work release candidates dont work featurebased releases dont work however im practice branching release stabilize assumedcrazy trunk prefer general way things releases made trunk code kept highquality possible small changes made directly trunk large changes made branch merged trunk ready agree details may ripe improvement however seems implicit assumption least us merge back trunk even needs nothing affair traditionally mergebacks small frequent live longlived branches problem isnt branches live long problem features big take long develop small working isolated steps always better big thuds branches seem protect us big thuds keeping trunk stable cant keep branch stable well theres another problem obvious anyone watched concurrency branch c tue 05 aug 2008 125423 0700 branching