I like that model, seems better suited for git; there should be two separate repositories then - 1.4 and 1.5

Aleksandar Fabijanic

Sent from my iPhone

On Oct 16, 2012, at 22:10, Franky Braem <franky.braem@gmail.com> wrote:

In my projects I do it as follow: I immediately create a branch for the next version from the master and start developing in that branch. When the version is released I merge it to the master. So the master always is the latest released version.

Franky

Sent from my Android

Op 16 okt. 2012 20:55 schreef "Günter Obiltschnig" <guenter.obiltschnig@appinf.com> het volgende:
Well, essentially we only have two branches to work on, master (ex trunk) and 1.4.4/5.
Ongoing development should happen in master*. When it's time to release we create a release branch (e.g., 1.5.1) from master.
Release branches then essentially become read-only, except for patches (e.g. those nasty patch releases).

Since working with branches (including merging) should be really easy in git (at least that's what the git people say...), this should not be an issue.

* That actually means, ongoing development happens in local repositories or maybe even private branches, with suitable changes then pushed to master.

--
Günter Obiltschnig
Applied Informatics Software Engineering GmbH
A-9182 Maria Elend | Maria Elend 96/4 | www.appinf.com
P: +43 4253 32596  M: +43 676 5166737  F: +43 4253 32096

Company Registration: FN 276491 f | Landesgericht Klagenfurt
Managing Director: DI Günter Obiltschnig



On 16.10.2012, at 20:35, Alex Fabijanic wrote:

> I agree, given the ease and visibility of github forking, there is no need for sandbox. Old SF SVN is still up and anyone can get a chunk of it out, start a github repo and propose/get it added to Poco master when ready.
>
> In regards to trunk:
>
> Shall we still keep trunk or should we just go with release branches? Multiple branches are a pain to keep in sync and I'm already concerned enough about keeping 1.5 synced with 1.4. Add trunk to the mix and we are setting ourselves for failure.
>
> I vote for no more than two active branches at any given time, meaning 1.4 and 1.5 branches only at this time.
>
> Aleksandar Fabijanic
>
> Sent from my iPhone
>
> On Oct 16, 2012, at 11:23, Franky Braem <franky.braem@gmail.com> wrote:
>
>> To me the word sandbox means playing around (with POCO). Maybe we can
>> have some repository where we can put real contributions. Some projects
>> that don't need to be part of POCO, but are build with POCO and can be
>> useful for others (my MongoDB for example). Unlike the sandbox, where a
>> lot of unfinished code is stored, these contributions must follow the
>> same standard rules as the POCO core. Instead of writing code in the
>> sandbox, I would write the code first in my forked repository and only
>> pull it when I think it is ready for others to use. So I don't think we
>> need a specific sandbox repository anymore.
>>
>> just my thoughts,
>>
>> Franky.
>>
>> On 10/16/2012 08:07 PM, Günter Obiltschnig wrote:
>>> Hi,
>>>
>>> I'm thinking about how to create and organize the POCO repository on GitHub.
>>> My plan for now is to create a local git repository using svn2git from our SourceForge SVN repository, but importing only the trunk and branches.
>>> Following command does this (already tested):
>>>
>>> $ svn2git https://poco.svn.sourceforge.net/svnroot/poco/poco --exclude trunk-1.1 --exclude trunk-1.2 --exclude articles --trunk trunk --branches branches --notags --authors ~/pocosvnusers.txt --no-minimize-url
>>>
>>> Then I would delete all old branches prior to 1.4.0. I don't think it makes sense to import the complete POCO history over to GitHub.
>>> The resulting local git repository would then be pushed to the GitHub poco repository.
>>> I will then create a separate repository for the sandbox. We can then decide which sandbox projects we'll transfer over to GitHub.
>>>
>>> The advantage of this approach would be that we have both 1.4 and trunk/1.5 in the same GitHub repository (as opposed to my original plan of having separate repositories), just in different branches. That means less confusion for users.
>>>
>>> Any comments?
>>>
>>> Günter
>>>
>>> --
>>> Günter Obiltschnig
>>> Applied Informatics Software Engineering GmbH
>>> A-9182 Maria Elend | Maria Elend 96/4 | www.appinf.com
>>> P: +43 4253 32596  M: +43 676 5166737  F: +43 4253 32096
>>>
>>> Company Registration: FN 276491 f | Landesgericht Klagenfurt
>>> Managing Director: DI Günter Obiltschnig
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>> Deploy New Relic app performance management and know exactly
>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>> http://p.sf.net/sfu/newrelic-dev2dev
>>> _______________________________________________
>>> poco-develop mailing list
>>> poco-develop@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/poco-develop
>>
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> poco-develop mailing list
>> poco-develop@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/poco-develop
>>
>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
poco-develop mailing list
poco-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/poco-develop