some thoughts on our build process
Krzysztof Koźmic
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
Craig Neuwirt
While this painful process is in your head, would you mind sharing it with me since I plan to now release WCF Facility. In particular, have you been maintaining any of the git commands procedures you had to do. Just curious to compare against what I did and see if we can at leasts commonlize the steps.
craig
> --
> 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 castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
>
Krzysztof Koźmic
1. I made sure everything compiles and all the tests run for each of 5
versions I released.
2. I went to TeamCity and set TeamCity build counter to the same
number for each version so that they all get released with the same
number (2.5.0.2108) (I picked date because it seemed like a better
choice than any other arbitrary number - in the future I suggest we
use #number of revisions since last release)
3. I updated changes.txt changing first line from "unreleased" to "2.5 (date)"
4. I downloaded all the files from team city and packaged them into
.zip, adding all additional files, like license.txt, committers.txt
(do we plan to update the file, there's a lot of people on the list I
haven't seen around for a while), changes.txt and breakingchanges.txt.
I also made subfolder for each of the 5 versions we ship, and I put
all the non-mandatory binaries (facilities, for Windsor, Logging
Components for Core) in subfolders, because I had feedback from people
that they are confused and it's not obvious what assemblies are
optional, which are mandatory)
5. I uploaded the files to SourceForge, created folders for the
release and placed the files there
6. I pinned the builds in TeamCity.
7. I created a tag (2.5.0) for each of the releases in Git
8. I created a branch (2.5.x) for each of the releases in Git
9. I created a blogpost with announcement, as well as announced the
release on Users and Devel group
10. (DIDN'T PUSH YET) I updated the mainsite news with the
announcement, I updated the Downloads page with new links, and I
updated the Projects page with new links dates and tentative release
date for v3 (TBD for many people is as good as "The project is dead"
so I'm trying to keep the impression that the project is being
developed).
11. I created release notes page in the
wiki:http://stw.castleproject.org/Windsor.Windsor_25_release_notes.ashx
12. I created a page in the wiki that describes sample app we have
(just one so far)
http://stw.castleproject.org/Windsor.Silvertlight_Sample_App_Customer_contact_manager.ashx
(the page is work in progress, I didn't have time to finish it)
13. There's probably something I forgot about :)
2010/8/23 Craig Neuwirt <cneu...@gmail.com>:
Craig Neuwirt
Krzysztof Koźmic
we really need docs for the facility BTW. like _really_ really.
BTW, here's a SO question you might want to take a look at
http://stackoverflow.com/questions/3531770/including-exception-details-when-using-a-castle-wcf-facility-hosted-service
W dniu 23 sierpnia 2010 10:54 użytkownik Craig Neuwirt
<cneu...@gmail.com> napisał:
Craig Neuwirt
John Simons
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 <krzy...@kozmic.pl>
To: Castle Project Devel <castle-pro...@googlegroups.com>
Sent: Sun, 22 August, 2010 9:26:34 PM
Subject: some thoughts on our build process
To post to this group, send email to castle-pro...@googlegroups.com.
John Simons
Just asking!
John
From: Krzysztof Koźmic <krzy...@kozmic.pl>
To: Castle Project Devel <castle-pro...@googlegroups.com>
Sent: Sun, 22 August, 2010 9:26:34 PM
Subject: some thoughts on our build process
Krzysztof Koźmic
so many things to look after and take care of is PITA. It took me a
few hours to get this thing out the door. Uploading to SF is just one
thing, but pretty much everything can be automated, including making
announcement on the groups and updating website.
Having numbers on builds between different versions just minimizes
overhead when trying to work out issues people have. Being able to
correlate build number to source code revision is very important IMO.
Krzysztof
2010/8/23 John Simons <johnsi...@yahoo.com.au>:
> castle-project-d...@googlegroups.com.
> 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 castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to
> castle-project-d...@googlegroups.com.
John Simons
By the release number I mean major.minor.revision, build number is not important.
We talked about this before and we agreed to only use major.minor.revision to identify releases. I think was Jono that proposed it, can't remember when, sorry!
Cheers
John
From: Krzysztof Koźmic <krzyszto...@gmail.com>
To: castle-pro...@googlegroups.com
Sent: Mon, 23 August, 2010 4:01:04 PM
Subject: Re: some thoughts on our build process
> 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 castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to
> 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 castle-pro...@googlegroups.com.
Jonathon Rossi
Yes, I proposed we only use the first 3 components of the version number probably 6 months ago and IIRC we agreed that is the way to go. We should either make the last component of the file version a build number or empty; and get the git revision into another field.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
--
Jono
Henry Conceição
server with a limited bandwidth.
Cheers,
Henry Conceição
2010/8/23 John Simons <johnsi...@yahoo.com.au>:
> castle-project-d...@googlegroups.com.
> 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 castle-pro...@googlegroups.com.
> To unsubscribe from this group, send email to
> castle-project-d...@googlegroups.com.
SerialSeb
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 <henry.concei...@gmail.com> 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
>
>
>
> > 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
>
> > ________________________________
>
> - Show quoted text -
Krzysztof Koźmic
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
Henry Conceição
generate a signed assemblies with references for unsigned assemblies.
Cheers,
Henry Conceição
2010/8/24 Krzysztof Koźmic <krzyszto...@gmail.com>: