Your comments please: How should we handle branching?

Coordinator
Aug 23, 2012 at 10:52 PM

Currently, the .NET Bio project exists in a single TFS branch, which makes maintenance trivial and simplifies versioning; as a project staffed by volunteers, simplicity is a distinct advantage – if we maintained multiple branches, we would have to handle issues of synchronizing code updates across all active branches. Also, CodePlex source downloads always give you all branches, which can be unwieldy and confusing.

As the release dates for Visual Studio 2012 and .NET 4.5 come closer, we need to ensure compatibility with these new releases. My suggestion is:

1.       We retain the single-branch approach in TFS

2.       We wait until the new releases have been current for at least six months, to ensure stability and widespread usage

3.       We generate a release, which will be the final version created with a requirement of VS2010/.NET 4.0 - this will be retained in the downloads for the foreseeable future.

4.       We change our software requirements to VS2012/.NET 4.5, test compatibility and resolve any issues, then generate a new release matching the new requirements. This will become the recommended release.

 

I’d be very interested to get feedback from those using .NET Bio – would this work for you? If not, what do you see as the main problems and how would you like to see them addressed?

 Thanks,

 

Simon

 

Coordinator
Aug 28, 2012 at 9:03 PM

We didn’t use .Net Bio much recently, but we are now starting again. I think the approach below is very good, I would prefer avoiding branching if possible, and I think we should just transition to .Net 4.5 instead.

Best,

Jarek

From: sjmercer [email removed]
Sent: Thursday, August 23, 2012 6:53 PM
To: Jaroslaw Pillardy
Subject: Your comments please: How should we handle branching? [bio:392885]

From: sjmercer

Currently, the .NET Bio project exists in a single TFS branch, which makes maintenance trivial and simplifies versioning; as a project staffed by volunteers, simplicity is a distinct advantage – if we maintained multiple branches, we would have to handle issues of synchronizing code updates across all active branches. Also, CodePlex source downloads always give you all branches, which can be unwieldy and confusing.

As the release dates for Visual Studio 2012 and .NET 4.5 come closer, we need to ensure compatibility with these new releases. My suggestion is:

1. We retain the single-branch approach in TFS

2. We wait until the new releases have been current for at least six months, to ensure stability and widespread usage

3. We generate a release, which will be the final version created with a requirement of VS2010/.NET 4.0 - this will be retained in the downloads for the foreseeable future.

4. We change our software requirements to VS2012/.NET 4.5, test compatibility and resolve any issues, then generate a new release matching the new requirements. This will become the recommended release.

I’d be very interested to get feedback from those using .NET Bio – would this work for you? If not, what do you see as the main problems and how would you like to see them addressed?

Thanks,

Simon

Coordinator
Aug 28, 2012 at 9:09 PM
I don't think there's any need to do anything. .NET 4.5 is a in-place update - if you install it, it replaces .NET 4.0 for all applications. So, if you install .NET 4.5 and then run a .NET Bio app, you are running on .NET 4.5 even if you compiled under 4.0. There's no need to branch or update any source code.

mark

On Aug 28, 2012, at 4:03 PM, jarekpillardy <notifications@codeplex.com> wrote:

From: jarekpillardy

We didn’t use .Net Bio much recently, but we are now starting again. I think the approach below is very good, I would prefer avoiding branching if possible, and I think we should just transition to .Net 4.5 instead.


Best,


Jarek


From: sjmercer [email removed]
Sent: Thursday, August 23, 2012 6:53 PM
To: Jaroslaw Pillardy
Subject: Your comments please: How should we handle branching? [bio:392885]


From: sjmercer

Currently, the .NET Bio project exists in a single TFS branch, which makes maintenance trivial and simplifies versioning; as a project staffed by volunteers, simplicity is a distinct advantage – if we maintained multiple branches, we would have to handle issues of synchronizing code updates across all active branches. Also, CodePlex source downloads always give you all branches, which can be unwieldy and confusing.

As the release dates for Visual Studio 2012 and .NET 4.5 come closer, we need to ensure compatibility with these new releases. My suggestion is:

1. We retain the single-branch approach in TFS

2. We wait until the new releases have been current for at least six months, to ensure stability and widespread usage

3. We generate a release, which will be the final version created with a requirement of VS2010/.NET 4.0 - this will be retained in the downloads for the foreseeable future.

4. We change our software requirements to VS2012/.NET 4.5, test compatibility and resolve any issues, then generate a new release matching the new requirements. This will become the recommended release.


I’d be very interested to get feedback from those using .NET Bio – would this work for you? If not, what do you see as the main problems and how would you like to see them addressed?

Thanks,


Simon



Coordinator
Aug 28, 2012 at 9:21 PM

Yes - it isn't that 4.5 needs changes to the code (until we test we can't cionfirm this, but it is highly likely) it is more that Visual Studio 2012, .NET 4.5 and WF 4, etc will become the new target configuration. This only makes sense some time after launch, of course.

 

Simon

 

Coordinator
Aug 28, 2012 at 9:32 PM
Even that should be ok. VS2010 and 2012 use the same project/solution format so it all works today without any upgrade. WF4 will be a change for the Workflow designer activities - which we could certainly branch (although I don't think we should), but that could be done independently of any update to 2012 or .NET 4.5. What I mean is that anyone pulling the code down today can choose either 2010 or 2012 right now without anything breaking. I use 2012 for all my updates now and have been since last year - targeting .NET 4.0. It is, for the most part, completely backward compatible.

mark


On Aug 28, 2012, at 4:21 PM, "sjmercer" <notifications@codeplex.com> wrote:

From: sjmercer

Yes - it isn't that 4.5 needs changes to the code (until we test we can't cionfirm this, but it is highly likely) it is more that Visual Studio 2012, .NET 4.5 and WF 4, etc will become the new target configuration. This only makes sense some time after launch, of course.


Simon