Releasing Castle projects guide

View: New views
6 Messages — Rating Filter:   Alert me  

Releasing Castle projects guide

by John Simons :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Some parts of this message have been removed. Learn more about Nabble's security policy.
There has been a lot of questions asked about on how to release Castle projects.
There is a lot of info everywhere but no single guide has ever been written that documents the procedure (as far as I know).
So this is my attempt to start one and hopefully other people will add/update this info so that we can eventually publish it on the Castle website.

Pre-requirements:
- You(or someone else) need to have svn write access;
- You need to be able to upload files to sf.net (http://sourceforge.net/projects/castleproject/), since sf.net has been updated the only people that are allowed to upload files are administrators;
- Make sure the website doco for your project is updated and ready to be committed as part of the release;
- You(or someone else) need to have writes to create a new "Build Configuration" in TeamCity;

If you don't have writes to do some of the above operations, do post a message on the mailing list for help.

Steps to create a new release:
- Make sure you are happy with the current version in your project trunk and all unit tests are passing in the buildserver;
  Also make sure that the package(zip file) that gets created automatically has all the files required for the release (look in the bin folder), if there are files missing check that the files are present in the build script, eg:
    <patternset id="package.bin.set" >
        <include name="Castle.ActiveRecord.dll" />
        <include name="Castle.ActiveRecord.xml" />
        <include name="Castle.ActiveRecord.Linq.dll" />
        <include name="Castle.ActiveRecord.Linq.xml" />
        <include name="Castle.Components.Validator.dll" />
        <include name="Castle.Components.Validator.xml" />
        <include name="Castle.Core.dll" />
        <include name="Castle.Core.xml" />
        <include name="Castle.DynamicProxy2.dll" />
        <include name="Castle.DynamicProxy2.xml" />
        <include name="log4net.dll" />
        <include name="log4net.xml" />
        <include name="log4net.license.txt" />
        <include name="NHibernate.Linq.dll" />
        <include name="NHibernate.Linq.xml" />
        <include name="Iesi.Collections.dll" />
        <include name="Iesi.Collections.xml" />
        <include name="Iesi.Collections.license.txt" />
        <include name="NHibernate.ByteCode.Castle.dll" />
        <include name="NHibernate.ByteCode.Castle.xml" />
        <include name="NHibernate.dll" />
        <include name="NHibernate.xml" />
        <include name="NHibernate.Search.dll" />
    </patternset>

- Modify the build scripts to update the assembly version of all assemblies you are releasing, eg:
    Before:
        ...
        <target name="init" depends="common.init">
            <property name="assembly.version" value="1.0.0.0" />   <!-- OLD Assembly version -->
            <property name="assembly.description" value="Windsor is an inversion of control container that aggregates the MicroKernel offering a friendly fool-proof interface and options to external configurations" />
            <assemblyfileset id="project.references" basedir="${build.dir}">
        ...

    After:
        ...
        <target name="init" depends="common.init">
            <property name="assembly.version" value="1.1.0.0" />   <!-- NEW Assembly version -->
            <property name="assembly.description" value="Windsor is an inversion of control container that aggregates the MicroKernel offering a friendly fool-proof interface and options to external configurations" />
            <assemblyfileset id="project.references" basedir="${build.dir}">
        ...

- Commit changes; note revision number xxx
- Run the trunk TeamCity build and ensure all tests are still passing;
- Create a tag from the xxx revision number, if you are versioning your release eg 1.1.0 then call your tag 1.1.0;
- Get the zip package from the artifacts of the trunk TeamCity build, the file is called something like "castle-activerecord-net-3.5-release-15.zip";
- Unzip this file in your workstation and ensure all files required are in the bin folder;
- Upload zip file to sf.net;
- Commit the changes to the documentation on the Castle website;
- Send an email to both castle-project-devel@... and castle-project-users@... announcing the release;
- Announce the release on the front page of the Castle website; <- This step can be done as part of committing the changes to the documentation
- You are done :)


Note:
I did not create a branch, a branch is only required if you encounter a bug in the release and need to put a fix for that release.


Steps to apply a patch(fix) to an existing release(that does not have a branch):
-
Find the tag for the release that requires fixing and create a branch from the tag;
- Create a new Build Configuration in TeamCity to build the new created branch:
        The simplest way to do this is to copy the trunk one and then modify the checkout rules.
- Get the branch and apply the patch or whatever fixes you have;
- Commit your changes to the branch;
- Run the new TeamCity build and ensure all tests are passing;
- From here on follow the instructions above to "create a new release";
   
Thoughts?

Cheers
John



Get more done like never before with Yahoo!7 Mail. Learn more.
--~--~---------~--~----~------------~-------~--~----~
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-project-devel@...
To unsubscribe from this group, send email to castle-project-devel+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en
-~----------~----~----~----~------~----~------~--~---


Re: Releasing Castle projects guide

by Jonathon Rossi :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Sounds good.

I think most the time it is worth creating a branch, and releasing from the branch (then tagging from the branch). We do need to get better at releasing bug fixes for released versions.

I think the first thing to do now is to get this into the castle web site, where others can improve on it.

On Thu, Oct 29, 2009 at 3:17 PM, John Simons <johnsimons007@...> wrote:
There has been a lot of questions asked about on how to release Castle projects.
There is a lot of info everywhere but no single guide has ever been written that documents the procedure (as far as I know).
So this is my attempt to start one and hopefully other people will add/update this info so that we can eventually publish it on the Castle website.

Pre-requirements:
- You(or someone else) need to have svn write access;
- You need to be able to upload files to sf.net (http://sourceforge.net/projects/castleproject/), since sf.net has been updated the only people that are allowed to upload files are administrators;
- Make sure the website doco for your project is updated and ready to be committed as part of the release;
- You(or someone else) need to have writes to create a new "Build Configuration" in TeamCity;

If you don't have writes to do some of the above operations, do post a message on the mailing list for help.

Steps to create a new release:
- Make sure you are happy with the current version in your project trunk and all unit tests are passing in the buildserver;
  Also make sure that the package(zip file) that gets created automatically has all the files required for the release (look in the bin folder), if there are files missing check that the files are present in the build script, eg:
    <patternset id="package.bin.set" >
        <include name="Castle.ActiveRecord.dll" />
        <include name="Castle.ActiveRecord.xml" />
        <include name="Castle.ActiveRecord.Linq.dll" />
        <include name="Castle.ActiveRecord.Linq.xml" />
        <include name="Castle.Components.Validator.dll" />
        <include name="Castle.Components.Validator.xml" />
        <include name="Castle.Core.dll" />
        <include name="Castle.Core.xml" />
        <include name="Castle.DynamicProxy2.dll" />
        <include name="Castle.DynamicProxy2.xml" />
        <include name="log4net.dll" />
        <include name="log4net.xml" />
        <include name="log4net.license.txt" />
        <include name="NHibernate.Linq.dll" />
        <include name="NHibernate.Linq.xml" />
        <include name="Iesi.Collections.dll" />
        <include name="Iesi.Collections.xml" />
        <include name="Iesi.Collections.license.txt" />
        <include name="NHibernate.ByteCode.Castle.dll" />
        <include name="NHibernate.ByteCode.Castle.xml" />
        <include name="NHibernate.dll" />
        <include name="NHibernate.xml" />
        <include name="NHibernate.Search.dll" />
    </patternset>

- Modify the build scripts to update the assembly version of all assemblies you are releasing, eg:
    Before:
        ...
        <target name="init" depends="common.init">
            <property name="assembly.version" value="1.0.0.0" />   <!-- OLD Assembly version -->
            <property name="assembly.description" value="Windsor is an inversion of control container that aggregates the MicroKernel offering a friendly fool-proof interface and options to external configurations" />
            <assemblyfileset id="project.references" basedir="${build.dir}">
        ...

    After:
        ...
        <target name="init" depends="common.init">
            <property name="assembly.version" value="1.1.0.0" />   <!-- NEW Assembly version -->
            <property name="assembly.description" value="Windsor is an inversion of control container that aggregates the MicroKernel offering a friendly fool-proof interface and options to external configurations" />
            <assemblyfileset id="project.references" basedir="${build.dir}">
        ...

- Commit changes; note revision number xxx
- Run the trunk TeamCity build and ensure all tests are still passing;
- Create a tag from the xxx revision number, if you are versioning your release eg 1.1.0 then call your tag 1.1.0;
- Get the zip package from the artifacts of the trunk TeamCity build, the file is called something like "castle-activerecord-net-3.5-release-15.zip";
- Unzip this file in your workstation and ensure all files required are in the bin folder;
- Upload zip file to sf.net;
- Commit the changes to the documentation on the Castle website;
- Send an email to both castle-project-devel@... and castle-project-users@... announcing the release;
- Announce the release on the front page of the Castle website; <- This step can be done as part of committing the changes to the documentation
- You are done :)


Note:
I did not create a branch, a branch is only required if you encounter a bug in the release and need to put a fix for that release.


Steps to apply a patch(fix) to an existing release(that does not have a branch):
-
Find the tag for the release that requires fixing and create a branch from the tag;
- Create a new Build Configuration in TeamCity to build the new created branch:
        The simplest way to do this is to copy the trunk one and then modify the checkout rules.
- Get the branch and apply the patch or whatever fixes you have;
- Commit your changes to the branch;
- Run the new TeamCity build and ensure all tests are passing;
- From here on follow the instructions above to "create a new release";
   
Thoughts?

Cheers
John



Get more done like never before with Yahoo!7 Mail. Learn more.




--
Jono

--~--~---------~--~----~------------~-------~--~----~
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-project-devel@...
To unsubscribe from this group, send email to castle-project-devel+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en
-~----------~----~----~----~------~----~------~--~---


Re: Releasing Castle projects guide

by John Simons :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


I was considering doing it that way too, but then YAGNI kicked in ;)
Anyway I think it works either way.

Cheers
John

On Oct 29, 4:29 pm, Jonathon Rossi <j...@...> wrote:

> Sounds good.
>
> I think most the time it is worth creating a branch, and releasing from the
> branch (then tagging from the branch). We do need to get better at releasing
> bug fixes for released versions.
>
> I think the first thing to do now is to get this into the castle web site,
> where others can improve on it.
>
> On Thu, Oct 29, 2009 at 3:17 PM, John Simons <johnsimons...@...>wrote:
>
>
>
> > There has been a lot of questions asked about on how to release Castle
> > projects.
> > There is a lot of info everywhere but no single guide has ever been written
> > that documents the procedure (as far as I know).
> > So this is my attempt to start one and hopefully other people will
> > add/update this info so that we can eventually publish it on the Castle
> > website.
>
> > Pre-requirements:
> > - You(or someone else) need to have svn write access;
> > - You need to be able to upload files to sf.net (
> >http://sourceforge.net/projects/castleproject/), since sf.net has been
> > updated the only people that are allowed to upload files are administrators;
> > - Make sure the website doco for your project is updated and ready to be
> > committed as part of the release;
> > - You(or someone else) need to have writes to create a new "Build
> > Configuration" in TeamCity;
>
> > If you don't have writes to do some of the above operations, do post a
> > message on the mailing list for help.
>
> > Steps to create a new release:
> > - Make sure you are happy with the current version in your project trunk
> > and all unit tests are passing in the buildserver;
> >   Also make sure that the package(zip file) that gets created automatically
> > has all the files required for the release (look in the bin folder), if
> > there are files missing check that the files are present in the build
> > script, eg:
> >     <patternset id="package.bin.set" >
> >         <include name="Castle.ActiveRecord.dll" />
> >         <include name="Castle.ActiveRecord.xml" />
> >         <include name="Castle.ActiveRecord.Linq.dll" />
> >         <include name="Castle.ActiveRecord.Linq.xml" />
> >         <include name="Castle.Components.Validator.dll" />
> >         <include name="Castle.Components.Validator.xml" />
> >         <include name="Castle.Core.dll" />
> >         <include name="Castle.Core.xml" />
> >         <include name="Castle.DynamicProxy2.dll" />
> >         <include name="Castle.DynamicProxy2.xml" />
> >         <include name="log4net.dll" />
> >         <include name="log4net.xml" />
> >         <include name="log4net.license.txt" />
> >         <include name="NHibernate.Linq.dll" />
> >         <include name="NHibernate.Linq.xml" />
> >         <include name="Iesi.Collections.dll" />
> >         <include name="Iesi.Collections.xml" />
> >         <include name="Iesi.Collections.license.txt" />
> >         <include name="NHibernate.ByteCode.Castle.dll" />
> >         <include name="NHibernate.ByteCode.Castle.xml" />
> >         <include name="NHibernate.dll" />
> >         <include name="NHibernate.xml" />
> >         <include name="NHibernate.Search.dll" />
> >     </patternset>
>
> > - Modify the build scripts to update the assembly version of all assemblies
> > you are releasing, eg:
> >     Before:
> >         ...
> >         <target name="init" depends="common.init">
> >             <property name="assembly.version" value="1.0.0.0" />   <!-- OLD
> > Assembly version -->
> >             <property name="assembly.description" value="Windsor is an
> > inversion of control container that aggregates the MicroKernel offering a
> > friendly fool-proof interface and options to external configurations" />
> >             <assemblyfileset id="project.references"
> > basedir="${build.dir}">
> >         ...
>
> >     After:
> >         ...
> >         <target name="init" depends="common.init">
> >             <property name="assembly.version" value="1.1.0.0" />   <!-- NEW
> > Assembly version -->
> >             <property name="assembly.description" value="Windsor is an
> > inversion of control container that aggregates the MicroKernel offering a
> > friendly fool-proof interface and options to external configurations" />
> >             <assemblyfileset id="project.references"
> > basedir="${build.dir}">
> >         ...
>
> > - Commit changes; note revision number xxx
> > - Run the trunk TeamCity build and ensure all tests are still passing;
> > - Create a tag from the xxx revision number, if you are versioning your
> > release eg 1.1.0 then call your tag 1.1.0;
> > - Get the zip package from the artifacts of the trunk TeamCity build, the
> > file is called something like "castle-activerecord-net-3.5-release-15.zip";
> > - Unzip this file in your workstation and ensure all files required are in
> > the bin folder;
> > - Upload zip file to sf.net;
> > - Commit the changes to the documentation on the Castle website;
> > - Send an email to both castle-project-devel@... and
> > castle-project-users@... announcing the release;
> > - Announce the release on the front page of the Castle website; <- This
> > step can be done as part of committing the changes to the documentation
> > - You are done :)
>
> > Note:
> > I did not create a branch, a branch is only required if you encounter a bug
> > in the release and need to put a fix for that release.
>
> > Steps to apply a patch(fix) to an existing release(that does not have a
> > branch):
> > - Find the tag for the release that requires fixing and create a branch
> > from the tag;
> > - Create a new Build Configuration in TeamCity to build the new created
> > branch:
> >         The simplest way to do this is to copy the trunk one and then
> > modify the checkout rules.
> > - Get the branch and apply the patch or whatever fixes you have;
> > - Commit your changes to the branch;
> > - Run the new TeamCity build and ensure all tests are passing;
> > - From here on follow the instructions above to "create a new release";
>
> > Thoughts?
>
> > Cheers
> > John
>
> > ------------------------------
> > Get more done like never before with Yahoo!7 Mail. Learn more<http://au.rd.yahoo.com/mail/launch09/tagline/*http://us.lrd.yahoo.com...>
> > .
>
> --
> Jono
--~--~---------~--~----~------------~-------~--~----~
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-project-devel@...
To unsubscribe from this group, send email to castle-project-devel+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en
-~----------~----~----~----~------~----~------~--~---


Re: Releasing Castle projects guide

by Krzysztof Koźmic :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Put it on the website somewhere guys, so that it does not drown in the
sea of messages on the list

Krzysztof

John Simons wrote:

> I was considering doing it that way too, but then YAGNI kicked in ;)
> Anyway I think it works either way.
>
> Cheers
> John
>
> On Oct 29, 4:29 pm, Jonathon Rossi <j...@...> wrote:
>  
>> Sounds good.
>>
>> I think most the time it is worth creating a branch, and releasing from the
>> branch (then tagging from the branch). We do need to get better at releasing
>> bug fixes for released versions.
>>
>> I think the first thing to do now is to get this into the castle web site,
>> where others can improve on it.
>>
>> On Thu, Oct 29, 2009 at 3:17 PM, John Simons <johnsimons...@...>wrote:
>>
>>
>>
>>    
>>> There has been a lot of questions asked about on how to release Castle
>>> projects.
>>> There is a lot of info everywhere but no single guide has ever been written
>>> that documents the procedure (as far as I know).
>>> So this is my attempt to start one and hopefully other people will
>>> add/update this info so that we can eventually publish it on the Castle
>>> website.
>>>      
>>> Pre-requirements:
>>> - You(or someone else) need to have svn write access;
>>> - You need to be able to upload files to sf.net (
>>> http://sourceforge.net/projects/castleproject/), since sf.net has been
>>> updated the only people that are allowed to upload files are administrators;
>>> - Make sure the website doco for your project is updated and ready to be
>>> committed as part of the release;
>>> - You(or someone else) need to have writes to create a new "Build
>>> Configuration" in TeamCity;
>>>      
>>> If you don't have writes to do some of the above operations, do post a
>>> message on the mailing list for help.
>>>      
>>> Steps to create a new release:
>>> - Make sure you are happy with the current version in your project trunk
>>> and all unit tests are passing in the buildserver;
>>>   Also make sure that the package(zip file) that gets created automatically
>>> has all the files required for the release (look in the bin folder), if
>>> there are files missing check that the files are present in the build
>>> script, eg:
>>>     <patternset id="package.bin.set" >
>>>         <include name="Castle.ActiveRecord.dll" />
>>>         <include name="Castle.ActiveRecord.xml" />
>>>         <include name="Castle.ActiveRecord.Linq.dll" />
>>>         <include name="Castle.ActiveRecord.Linq.xml" />
>>>         <include name="Castle.Components.Validator.dll" />
>>>         <include name="Castle.Components.Validator.xml" />
>>>         <include name="Castle.Core.dll" />
>>>         <include name="Castle.Core.xml" />
>>>         <include name="Castle.DynamicProxy2.dll" />
>>>         <include name="Castle.DynamicProxy2.xml" />
>>>         <include name="log4net.dll" />
>>>         <include name="log4net.xml" />
>>>         <include name="log4net.license.txt" />
>>>         <include name="NHibernate.Linq.dll" />
>>>         <include name="NHibernate.Linq.xml" />
>>>         <include name="Iesi.Collections.dll" />
>>>         <include name="Iesi.Collections.xml" />
>>>         <include name="Iesi.Collections.license.txt" />
>>>         <include name="NHibernate.ByteCode.Castle.dll" />
>>>         <include name="NHibernate.ByteCode.Castle.xml" />
>>>         <include name="NHibernate.dll" />
>>>         <include name="NHibernate.xml" />
>>>         <include name="NHibernate.Search.dll" />
>>>     </patternset>
>>>      
>>> - Modify the build scripts to update the assembly version of all assemblies
>>> you are releasing, eg:
>>>     Before:
>>>         ...
>>>         <target name="init" depends="common.init">
>>>             <property name="assembly.version" value="1.0.0.0" />   <!-- OLD
>>> Assembly version -->
>>>             <property name="assembly.description" value="Windsor is an
>>> inversion of control container that aggregates the MicroKernel offering a
>>> friendly fool-proof interface and options to external configurations" />
>>>             <assemblyfileset id="project.references"
>>> basedir="${build.dir}">
>>>         ...
>>>      
>>>     After:
>>>         ...
>>>         <target name="init" depends="common.init">
>>>             <property name="assembly.version" value="1.1.0.0" />   <!-- NEW
>>> Assembly version -->
>>>             <property name="assembly.description" value="Windsor is an
>>> inversion of control container that aggregates the MicroKernel offering a
>>> friendly fool-proof interface and options to external configurations" />
>>>             <assemblyfileset id="project.references"
>>> basedir="${build.dir}">
>>>         ...
>>>      
>>> - Commit changes; note revision number xxx
>>> - Run the trunk TeamCity build and ensure all tests are still passing;
>>> - Create a tag from the xxx revision number, if you are versioning your
>>> release eg 1.1.0 then call your tag 1.1.0;
>>> - Get the zip package from the artifacts of the trunk TeamCity build, the
>>> file is called something like "castle-activerecord-net-3.5-release-15.zip";
>>> - Unzip this file in your workstation and ensure all files required are in
>>> the bin folder;
>>> - Upload zip file to sf.net;
>>> - Commit the changes to the documentation on the Castle website;
>>> - Send an email to both castle-project-devel@... and
>>> castle-project-users@... announcing the release;
>>> - Announce the release on the front page of the Castle website; <- This
>>> step can be done as part of committing the changes to the documentation
>>> - You are done :)
>>>      
>>> Note:
>>> I did not create a branch, a branch is only required if you encounter a bug
>>> in the release and need to put a fix for that release.
>>>      
>>> Steps to apply a patch(fix) to an existing release(that does not have a
>>> branch):
>>> - Find the tag for the release that requires fixing and create a branch
>>> from the tag;
>>> - Create a new Build Configuration in TeamCity to build the new created
>>> branch:
>>>         The simplest way to do this is to copy the trunk one and then
>>> modify the checkout rules.
>>> - Get the branch and apply the patch or whatever fixes you have;
>>> - Commit your changes to the branch;
>>> - Run the new TeamCity build and ensure all tests are passing;
>>> - From here on follow the instructions above to "create a new release";
>>>      
>>> Thoughts?
>>>      
>>> Cheers
>>> John
>>>      
>>> ------------------------------
>>> Get more done like never before with Yahoo!7 Mail. Learn more<http://au.rd.yahoo.com/mail/launch09/tagline/*http://us.lrd.yahoo.com...>
>>> .
>>>      
>> --
>> Jono
>>    
> >
>  


--~--~---------~--~----~------------~-------~--~----~
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-project-devel@...
To unsubscribe from this group, send email to castle-project-devel+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en
-~----------~----~----~----~------~----~------~--~---


Re: Releasing Castle projects guide

by John Simons :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


I intend to, I was thinking of creating a new page under Community,
any objections?

John

On Oct 29, 6:52 pm, Krzysztof Koźmic <krzysztof.koz...@...>
wrote:

> Put it on the website somewhere guys, so that it does not drown in the
> sea of messages on the list
>
> Krzysztof
>
> John Simons wrote:
> > I was considering doing it that way too, but then YAGNI kicked in ;)
> > Anyway I think it works either way.
>
> > Cheers
> > John
>
> > On Oct 29, 4:29 pm, Jonathon Rossi <j...@...> wrote:
>
> >> Sounds good.
>
> >> I think most the time it is worth creating a branch, and releasing from the
> >> branch (then tagging from the branch). We do need to get better at releasing
> >> bug fixes for released versions.
>
> >> I think the first thing to do now is to get this into the castle web site,
> >> where others can improve on it.
>
> >> On Thu, Oct 29, 2009 at 3:17 PM, John Simons <johnsimons...@...>wrote:
>
> >>> There has been a lot of questions asked about on how to release Castle
> >>> projects.
> >>> There is a lot of info everywhere but no single guide has ever been written
> >>> that documents the procedure (as far as I know).
> >>> So this is my attempt to start one and hopefully other people will
> >>> add/update this info so that we can eventually publish it on the Castle
> >>> website.
>
> >>> Pre-requirements:
> >>> - You(or someone else) need to have svn write access;
> >>> - You need to be able to upload files to sf.net (
> >>>http://sourceforge.net/projects/castleproject/), since sf.net has been
> >>> updated the only people that are allowed to upload files are administrators;
> >>> - Make sure the website doco for your project is updated and ready to be
> >>> committed as part of the release;
> >>> - You(or someone else) need to have writes to create a new "Build
> >>> Configuration" in TeamCity;
>
> >>> If you don't have writes to do some of the above operations, do post a
> >>> message on the mailing list for help.
>
> >>> Steps to create a new release:
> >>> - Make sure you are happy with the current version in your project trunk
> >>> and all unit tests are passing in the buildserver;
> >>>   Also make sure that the package(zip file) that gets created automatically
> >>> has all the files required for the release (look in the bin folder), if
> >>> there are files missing check that the files are present in the build
> >>> script, eg:
> >>>     <patternset id="package.bin.set" >
> >>>         <include name="Castle.ActiveRecord.dll" />
> >>>         <include name="Castle.ActiveRecord.xml" />
> >>>         <include name="Castle.ActiveRecord.Linq.dll" />
> >>>         <include name="Castle.ActiveRecord.Linq.xml" />
> >>>         <include name="Castle.Components.Validator.dll" />
> >>>         <include name="Castle.Components.Validator.xml" />
> >>>         <include name="Castle.Core.dll" />
> >>>         <include name="Castle.Core.xml" />
> >>>         <include name="Castle.DynamicProxy2.dll" />
> >>>         <include name="Castle.DynamicProxy2.xml" />
> >>>         <include name="log4net.dll" />
> >>>         <include name="log4net.xml" />
> >>>         <include name="log4net.license.txt" />
> >>>         <include name="NHibernate.Linq.dll" />
> >>>         <include name="NHibernate.Linq.xml" />
> >>>         <include name="Iesi.Collections.dll" />
> >>>         <include name="Iesi.Collections.xml" />
> >>>         <include name="Iesi.Collections.license.txt" />
> >>>         <include name="NHibernate.ByteCode.Castle.dll" />
> >>>         <include name="NHibernate.ByteCode.Castle.xml" />
> >>>         <include name="NHibernate.dll" />
> >>>         <include name="NHibernate.xml" />
> >>>         <include name="NHibernate.Search.dll" />
> >>>     </patternset>
>
> >>> - Modify the build scripts to update the assembly version of all assemblies
> >>> you are releasing, eg:
> >>>     Before:
> >>>         ...
> >>>         <target name="init" depends="common.init">
> >>>             <property name="assembly.version" value="1.0.0.0" />   <!-- OLD
> >>> Assembly version -->
> >>>             <property name="assembly.description" value="Windsor is an
> >>> inversion of control container that aggregates the MicroKernel offering a
> >>> friendly fool-proof interface and options to external configurations" />
> >>>             <assemblyfileset id="project.references"
> >>> basedir="${build.dir}">
> >>>         ...
>
> >>>     After:
> >>>         ...
> >>>         <target name="init" depends="common.init">
> >>>             <property name="assembly.version" value="1.1.0.0" />   <!-- NEW
> >>> Assembly version -->
> >>>             <property name="assembly.description" value="Windsor is an
> >>> inversion of control container that aggregates the MicroKernel offering a
> >>> friendly fool-proof interface and options to external configurations" />
> >>>             <assemblyfileset id="project.references"
> >>> basedir="${build.dir}">
> >>>         ...
>
> >>> - Commit changes; note revision number xxx
> >>> - Run the trunk TeamCity build and ensure all tests are still passing;
> >>> - Create a tag from the xxx revision number, if you are versioning your
> >>> release eg 1.1.0 then call your tag 1.1.0;
> >>> - Get the zip package from the artifacts of the trunk TeamCity build, the
> >>> file is called something like "castle-activerecord-net-3.5-release-15.zip";
> >>> - Unzip this file in your workstation and ensure all files required are in
> >>> the bin folder;
> >>> - Upload zip file to sf.net;
> >>> - Commit the changes to the documentation on the Castle website;
> >>> - Send an email to both castle-project-devel@... and
> >>> castle-project-users@... announcing the release;
> >>> - Announce the release on the front page of the Castle website; <- This
> >>> step can be done as part of committing the changes to the documentation
> >>> - You are done :)
>
> >>> Note:
> >>> I did not create a branch, a branch is only required if you encounter a bug
> >>> in the release and need to put a fix for that release.
>
> >>> Steps to apply a patch(fix) to an existing release(that does not have a
> >>> branch):
> >>> - Find the tag for the release that requires fixing and create a branch
> >>> from the tag;
> >>> - Create a new Build Configuration in TeamCity to build the new created
> >>> branch:
> >>>         The simplest way to do this is to copy the trunk one and then
> >>> modify the checkout rules.
> >>> - Get the branch and apply the patch or whatever fixes you have;
> >>> - Commit your changes to the branch;
> >>> - Run the new TeamCity build and ensure all tests are passing;
> >>> - From here on follow the instructions above to "create a new release";
>
> >>> Thoughts?
>
> >>> Cheers
> >>> John
>
> >>> ------------------------------
> >>> Get more done like never before with Yahoo!7 Mail. Learn more<http://au.rd.yahoo.com/mail/launch09/tagline/*http://us.lrd.yahoo.com...>
> >>> .
>
> >> --
> >> Jono
--~--~---------~--~----~------------~-------~--~----~
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-project-devel@...
To unsubscribe from this group, send email to castle-project-devel+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en
-~----------~----~----~----~------~----~------~--~---


Re: Releasing Castle projects guide

by John Simons :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


I've just committed this guide to the website.
Please have a look.

Cheers
John

On Oct 29, 7:54 pm, John Simons <johnsimons...@...> wrote:

> I intend to, I was thinking of creating a new page under Community,
> any objections?
>
> John
>
> On Oct 29, 6:52 pm, Krzysztof Koźmic <krzysztof.koz...@...>
> wrote:
>
> > Put it on the website somewhere guys, so that it does not drown in the
> > sea of messages on the list
>
> > Krzysztof
>
> > John Simons wrote:
> > > I was considering doing it that way too, but then YAGNI kicked in ;)
> > > Anyway I think it works either way.
>
> > > Cheers
> > > John
>
> > > On Oct 29, 4:29 pm, Jonathon Rossi <j...@...> wrote:
>
> > >> Sounds good.
>
> > >> I think most the time it is worth creating a branch, and releasing from the
> > >> branch (then tagging from the branch). We do need to get better at releasing
> > >> bug fixes for released versions.
>
> > >> I think the first thing to do now is to get this into the castle web site,
> > >> where others can improve on it.
>
> > >> On Thu, Oct 29, 2009 at 3:17 PM, John Simons <johnsimons...@...>wrote:
>
> > >>> There has been a lot of questions asked about on how to release Castle
> > >>> projects.
> > >>> There is a lot of info everywhere but no single guide has ever been written
> > >>> that documents the procedure (as far as I know).
> > >>> So this is my attempt to start one and hopefully other people will
> > >>> add/update this info so that we can eventually publish it on the Castle
> > >>> website.
>
> > >>> Pre-requirements:
> > >>> - You(or someone else) need to have svn write access;
> > >>> - You need to be able to upload files to sf.net (
> > >>>http://sourceforge.net/projects/castleproject/), since sf.net has been
> > >>> updated the only people that are allowed to upload files are administrators;
> > >>> - Make sure the website doco for your project is updated and ready to be
> > >>> committed as part of the release;
> > >>> - You(or someone else) need to have writes to create a new "Build
> > >>> Configuration" in TeamCity;
>
> > >>> If you don't have writes to do some of the above operations, do post a
> > >>> message on the mailing list for help.
>
> > >>> Steps to create a new release:
> > >>> - Make sure you are happy with the current version in your project trunk
> > >>> and all unit tests are passing in the buildserver;
> > >>>   Also make sure that the package(zip file) that gets created automatically
> > >>> has all the files required for the release (look in the bin folder), if
> > >>> there are files missing check that the files are present in the build
> > >>> script, eg:
> > >>>     <patternset id="package.bin.set" >
> > >>>         <include name="Castle.ActiveRecord.dll" />
> > >>>         <include name="Castle.ActiveRecord.xml" />
> > >>>         <include name="Castle.ActiveRecord.Linq.dll" />
> > >>>         <include name="Castle.ActiveRecord.Linq.xml" />
> > >>>         <include name="Castle.Components.Validator.dll" />
> > >>>         <include name="Castle.Components.Validator.xml" />
> > >>>         <include name="Castle.Core.dll" />
> > >>>         <include name="Castle.Core.xml" />
> > >>>         <include name="Castle.DynamicProxy2.dll" />
> > >>>         <include name="Castle.DynamicProxy2.xml" />
> > >>>         <include name="log4net.dll" />
> > >>>         <include name="log4net.xml" />
> > >>>         <include name="log4net.license.txt" />
> > >>>         <include name="NHibernate.Linq.dll" />
> > >>>         <include name="NHibernate.Linq.xml" />
> > >>>         <include name="Iesi.Collections.dll" />
> > >>>         <include name="Iesi.Collections.xml" />
> > >>>         <include name="Iesi.Collections.license.txt" />
> > >>>         <include name="NHibernate.ByteCode.Castle.dll" />
> > >>>         <include name="NHibernate.ByteCode.Castle.xml" />
> > >>>         <include name="NHibernate.dll" />
> > >>>         <include name="NHibernate.xml" />
> > >>>         <include name="NHibernate.Search.dll" />
> > >>>     </patternset>
>
> > >>> - Modify the build scripts to update the assembly version of all assemblies
> > >>> you are releasing, eg:
> > >>>     Before:
> > >>>         ...
> > >>>         <target name="init" depends="common.init">
> > >>>             <property name="assembly.version" value="1.0.0.0" />   <!-- OLD
> > >>> Assembly version -->
> > >>>             <property name="assembly.description" value="Windsor is an
> > >>> inversion of control container that aggregates the MicroKernel offering a
> > >>> friendly fool-proof interface and options to external configurations" />
> > >>>             <assemblyfileset id="project.references"
> > >>> basedir="${build.dir}">
> > >>>         ...
>
> > >>>     After:
> > >>>         ...
> > >>>         <target name="init" depends="common.init">
> > >>>             <property name="assembly.version" value="1.1.0.0" />   <!-- NEW
> > >>> Assembly version -->
> > >>>             <property name="assembly.description" value="Windsor is an
> > >>> inversion of control container that aggregates the MicroKernel offering a
> > >>> friendly fool-proof interface and options to external configurations" />
> > >>>             <assemblyfileset id="project.references"
> > >>> basedir="${build.dir}">
> > >>>         ...
>
> > >>> - Commit changes; note revision number xxx
> > >>> - Run the trunk TeamCity build and ensure all tests are still passing;
> > >>> - Create a tag from the xxx revision number, if you are versioning your
> > >>> release eg 1.1.0 then call your tag 1.1.0;
> > >>> - Get the zip package from the artifacts of the trunk TeamCity build, the
> > >>> file is called something like "castle-activerecord-net-3.5-release-15.zip";
> > >>> - Unzip this file in your workstation and ensure all files required are in
> > >>> the bin folder;
> > >>> - Upload zip file to sf.net;
> > >>> - Commit the changes to the documentation on the Castle website;
> > >>> - Send an email to both castle-project-devel@... and
> > >>> castle-project-users@... announcing the release;
> > >>> - Announce the release on the front page of the Castle website; <- This
> > >>> step can be done as part of committing the changes to the documentation
> > >>> - You are done :)
>
> > >>> Note:
> > >>> I did not create a branch, a branch is only required if you encounter a bug
> > >>> in the release and need to put a fix for that release.
>
> > >>> Steps to apply a patch(fix) to an existing release(that does not have a
> > >>> branch):
> > >>> - Find the tag for the release that requires fixing and create a branch
> > >>> from the tag;
> > >>> - Create a new Build Configuration in TeamCity to build the new created
> > >>> branch:
> > >>>         The simplest way to do this is to copy the trunk one and then
> > >>> modify the checkout rules.
> > >>> - Get the branch and apply the patch or whatever fixes you have;
> > >>> - Commit your changes to the branch;
> > >>> - Run the new TeamCity build and ensure all tests are passing;
> > >>> - From here on follow the instructions above to "create a new release";
>
> > >>> Thoughts?
>
> > >>> Cheers
> > >>> John
>
> > >>> ------------------------------
> > >>> Get more done like never before with Yahoo!7 Mail. Learn more<http://au.rd.yahoo.com/mail/launch09/tagline/*http://us.lrd.yahoo.com...>
> > >>> .
>
> > >> --
> > >> Jono
--~--~---------~--~----~------------~-------~--~----~
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-project-devel@...
To unsubscribe from this group, send email to castle-project-devel+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en
-~----------~----~----~----~------~----~------~--~---