What I want in the future is to be able to corelate each and every
binary we produce with revision that it was created from.
As far as I'm concerned we can always set revision part in version
number to 0 and have the git revision id stored somewhere else - I don't
really care (although I like the idea of counting number of commits
since last release).
Can anyone remind me why we're producing signed assemblies? (it's a
genune question). I know that it was required when Windsor had a
installer that was deploying the binaries to GAC, so is it just a
leftover or do we have some actual reasons for keeping on doing so?
Krzysztof
On 24/08/2010 5:38 PM, SerialSeb wrote:
Few notes that may be of interest for the castle project re: openwrap.
The version is only significant for its 3 compoents, the revision is
ignored when defining your dependencies; and the dlls for all profiles
can (and should) exist in the same package.
And finally, assembly signing is discouraged, to prevent breaking
binary compat across versions without having to deal with publisher
policies etc.
Seb
On Aug 23, 4:12 pm, Henry Conceição<[email protected]> wrote:
About the sf.net: Yes, since they have a cdn, and we only have one
server with a limited bandwidth.
Cheers,
Henry Conceição
2010/8/23 John Simons<[email protected]>:
Krzysztof,
In your opinion what are the major pain points?
To me one pain point is actually having to upload the zip onto sf.net. Is
there a reason why we still need to do this? Can we instead tag the teamcity
build and expose the zip as a link on the website?
John
________________________________
From: Krzysztof Koźmic<[email protected]>
To: Castle Project Devel<[email protected]>
Sent: Sun, 22 August, 2010 9:26:34 PM
Subject: some thoughts on our build process
Hey,
having gone throuh the pain of releasing Core and Windsor today I wanted to
say one thing - it's extremely painful to go thought. All the (many) steps
are manual and require a lot of time to complete. It took me half of the day
to get it all working and out the door. That's not how it should be. I
chatted with Roelof and he proposed that we should look into automating as
much of the process as possible. I couldn't agree more.
We should also change how we assing build numbers. Currently we use
autoincremented builds count from TeamCity which has the drawback that if we
release several version of the same project (for .NET 3.5, 4.0, 4.0 CP, two
versions of SIlverlight, possibly Mono in the future) all of them have
different numbers. For the release I manually set up the counter to be the
same for all builds but we should have it done automatically.
This is a major issue and to keep shipping the software on a sustainable
pace we need to streamline and automate it a lot.
Comments and ideas welcome.
Krzysztof
-- You received this message because you are subscribed to the Google Groups
"Castle Project Development List" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Castle Project Development List" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.- Hide quoted text -
- Show quoted text -
--
You received this message because you are subscribed to the Google Groups "Castle
Project Development List" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en.
