Versioning

[Naeem Khedarun]

From the comments on your announcement:

"Because all the .net binaries in the Bricks central repository are
unsigned"

Curiously, why not only handle signed assemblies and take advantage of
the GAC? If we did do it this way then:

-------
Developer starts a project. Does:

1) bricks install castle-activerecord (which installs assemblies into
the GAC)
2) Creates a project which references a specific version.
3) Notes down this version for use in the build scripts.

CI Build and deployment scripts would do:

bricks install castle-activerecord --version 2.0.213123
-------

There is no concept of 'update', since you would not replace existing
versions, simple get the latest version and put it in the GAC.

bricks install-latest castle-activerecord
or
bricks install castle-activerecord --latest
or
bricks install castle-activerecord --version latest

I suspect if we had a system like this which took advantage of the
GAC, more open source projects would strong name and correctly version
their assemblies...

--
You received this message because you are subscribed to the Google Groups "Bricks Development" group.
To post to this group, send email to bricks...@googlegroups.com.
To unsubscribe from this group, send email to bricks-devel...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/bricks-devel?hl=en.

[Jonathon Rossi]

Many people are doing xcopy deployment for .NET applications, especially web applications. So devs are going to want for Bricks to populate their lib directory and they will use that.

The other problem with strong names is that without binding redirects you must have the same version of the assembly your application was built with. This is much bigger problem when third party libraries like Castle and NHibernate want to release a bug fix, where it causes everyone depending on that library to re-release their library otherwise assembly bindings fail. Unsigned assemblies cannot be installed in the GAC, however .NET will look in the same directory as your application for the assembly.

Also because registering assemblies in the GAC requires administrator permissions it would be a little more difficult to achieve. I am not ruling this option out, but at the moment I think it is too difficult to achieve and a survey of a bunch of OSS devs said they don't install their application assemblies into the GAC so I thought it would be low priority.

I do plan for bricks do be able to do the following:

bricks install castle-activerecord // this would install 2.1.2
bricks install castle-activerecord-2.1.0 // this would install 2.1.0
bricks unpack castle-activerecord-2.1.0 // this would unpack the 2.1.0 binaries into the current directory
// If ActiveRecord 2.1.3 was released and available in the central repository
bricks upgrade // would install castle-activerecord-2.1.3, leaving 2.1.0 and 2.1.2 installed locally so you can choose which version your app needs

I'm happy to discuss what direction people would like Bricks to go in.

Many thanks for your comments.

--
Jono