Seb, Have u raised that with Jeremy and Dru?
________________________________ From: Sebastien Lambla <[email protected]> To: "[email protected]" <[email protected]> Sent: Saturday, 30 April 2011 6:48 PM Subject: RE: Our build scripts, nuget, openwrap and related stuff I think there’s little in bottles that couldn’t be merged back in openwrap tbh :) That said, we do have an API yes, although I’m aiming at API stability for the 1.2 release, so it depends on what part of the API you want to use. The commands API is stable though, and the UI API will be for 1.1, with the templates API reaching stability between 1.1 and 1.2. From:[email protected] [mailto:[email protected]] On Behalf Of John Simons Sent: 30 April 2011 01:47 To: [email protected] Cc: Hamilton Subject: Re: Our build scripts, nuget, openwrap and related stuff I forgot to mention that Dru is also planning to use bottles in TopShelf shelves. Cheers John ________________________________ From:John Simons <[email protected]> To: "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Sent: Saturday, 30 April 2011 10:42 AM Subject: Re: Our build scripts, nuget, openwrap and related stuff +1 to use/encourage/promote the usage of OW I'm of the opinion that we should use OW as our primary dependency management tool. I think we have much better chances of getting something changed or a patch committed into OR then Nuget. Nuget is as much open source as ASP.NET MVC is! Has anyone ever tried to get a patch accepted! Hamilton, Have u looked at bottles? See http://groups.google.com/group/fubumvc-devel/browse_thread/thread/931c3f5ec344472c I think this is exactly what you are talking about. ________________________________ From:hammett <[email protected]> To: [email protected] Sent: Saturday, 30 April 2011 4:11 AM Subject: Re: Our build scripts, nuget, openwrap and related stuff Thanks, Seb. It makes sense to support both, and I think we should aim at that. That said, I feel we - castle - should encourage OW over nuget as a community driven effort. I also want to include some built-in support for package (design/runtime) into MR+++ and obviously don't want to build it myself. I wonder if extensibility is a goal for OW, so products can use it to create their own package mechanism with custom deployments. On Fri, Apr 29, 2011 at 12:48 AM, SerialSeb <[email protected]> wrote: > Rafael, > > OpenWrap 1.0 has no VS integration support, because it doesn't need it > to function. > > In 1.1 we're extending the concept of project and system commands to > IDEs, so you can expect to see some preliminary UI support, both for > VS2008 and VS2010. For this releas however, I'm only committing to a > "current packages" toolwindow that exposes the current config and > which projects get what projects, as well as an "Enable OpenWrap" on > the project node. > > The rest of the UI integration work will be in 1.2, based on requests > and feedback, and on contributors joining the project to drive this if > they have the wish to do so. > > I'm fully aware that the integration of NuGet in VS makes people doubt > the value of an other package manager in the ecosystem. At the end of > the day, the same can be said about MonoRails / MVC. > > I'd recommend users to to make a commitment to a package manager or > another based on featureset and not on marketing dollars spent by MS. > Attetion shifts and what is a priority for them now won't necessarily > be in a year. Their commitment to the health of the OSS ecosystem is > also very much in doubt considering how NuGet came into existence, so > that's also for contributors to decide where they stand. > > I certainly wouldn't recommend for castle to only have one or the > other package format for users, maintaining two sets of packages is > perfectly doable, be it that you decide for yourself to use openwrap > or nuget for your dependencies as you build the stack. > > > On Apr 28, 1:06 pm, Rafael Teixeira <[email protected]> wrote: >> The great thing about NuGet is that it broke the "barrier" to >> find-and-deploy dependencies, and a big part of that is just the "Add >> Package Reference" item in the context menu of projects in VS, that can make >> people whose never thought of trying something like Castle easily try it and >> adopt. >> >> Does OpenWrap integrate so easily in VS? Installing NuGet support in VS2010 >> is a snap, and using it afterwards also is. More importantly MS (Haack/Ebbo >> mostly) has been evangelizing about it everywhere, and it is gaining >> momentum... >> >> So we probably should follow the "easier-for-our-adopters" path, which I >> think currently means NuGet. >> >> @SerialSeb, please can you tell us about the state/roadmap of OW-VS >> integration, so that we can try to settle this and move forward to really >> adopting some packaging strategy. >> >> Regards, >> >> Rafael "Monoman" Teixeira >> --------------------------------------- >> "The most exciting phrase to hear in science, the one that heralds new >> discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'" >> Isaac Asimov >> US science fiction novelist & scholar (1920 - 1992) >> >> >> >> On Wed, Apr 27, 2011 at 10:05 PM, hammett <[email protected]> wrote: >> > Hmm.. tough one. At least OW supports Nuget repositories. Not sure >> > about the other way round.. >> >> > On Wed, Apr 27, 2011 at 4:59 PM, John Simons <[email protected]> >> > wrote: >> > > Does this mean we need to decide to use either nuget or ow? >> > > Is there a good comparison of both? >> >> > > ________________________________ >> > > From: Krzysztof Koźmic <[email protected]> >> > > To: [email protected] >> > > Sent: Thursday, 28 April 2011 9:24 AM >> > > Subject: Re: Our build scripts, nuget, openwrap and related stuff >> >> > > Oh, hi Cristian :) >> >> > > Go for it mate. >> >> > > Krzysztof >> >> > > On 28/04/2011 9:23 AM, Cristian Prieto wrote: >> >> > > I raise my hand... >> > > Cristian Prieto >> >> > > On Thu, Apr 28, 2011 at 6:05 AM, Hammett <[email protected]> wrote: >> >> > > I like the idea. Who's stepping in to make it real, though? >> >> > > On 2011-04-27, at 5:32 AM, Rafael Teixeira <[email protected]> wrote: >> >> > > Just to cross-share some experience from Mono packaging for Debian/Ubuntu >> > > into Castle. Mirco Bauer just blogged on the reasoning for "The Big >> > > Split" >> >http://www.meebey.net/posts/the_big_split_mono_2.10_debian_packaging/. >> > > Summarizing it, Mono will be packaged from now on, on the basis of "ONE >> > > managed library per package" so that independently from the set of >> > managed >> > > apps that you install no "surplus" dlls and related dependency trees >> > > (managed and native) are installed because they were packaged together >> > with >> > > something that was needed, obviously there are meta-packages like >> > > mono-complete which install all the packages and the packagers do build >> > > everything from an specific snapshot of the whole source tree for Mono >> > and >> > > each managed app. >> > > To the practical point, with NuGet (or OpenWrap) we can package things >> > very >> > > granularly, and have the dependencies sort things for the user >> > (programmer), >> > > and we already do kind of it, but we need to use it ourselves, breaking >> > the >> > > ties from referencing directly lots of projects in one solution and >> > > referencing released versions of our own packages (or test versions from >> > a >> > > NuGet repo tied to Team City). >> > > With that we will lose the ability to make big refactorings across the >> > whole >> > > stack, but that may be, in essence, a GOOD thing, so that we are more >> > > conscious on API/Semantics breakages. That leeds to what really will >> > remain >> > > complex, dependency versioning, or how to set MaxVersion on dependencies >> > > (MinVersion is trivial). >> > > My suggestion: to adopt an even more strict policy on version numbers >> > versus >> > > API/Semantics breakage: Change the Minor and/or Major version when >> > > API/Semantics change, so set MaxVersion to an arbitrary high release >> > number >> > > on (build numbers should never matter) . Example: >> > > Castle.Windsor (3.0) depends on Castle.Core (3.0.0 to 3.0.1000). >> > > If you need to change a signature method on some Castle.Core >> > > interface/public class (even specifying optional parameters/default >> > values, >> > > or changing parameter names, now qualify as such) them you bump to 3.1.0 >> > and >> > > have to build new dependent versions of up-in-the-stack libraries . The >> > > remaining question is if some client library isn't affected by that API >> > > breakage (lots of test coverage needed to assert that), if we just >> > compile a >> > > new version extending the version range on the dependency bumping just >> > the >> > > release number, or we have to bump the minor, because of cascading >> > > dependencies breakage. Example >> > > Castle.Windsor (3.0) depends on Castle.Core (3.0.0 to 3.1.1000). >> > > -- or -- >> > > Castle.Windsor (3.1) depends on Castle.Core (3.1.0 to 3.1.1000). >> > > What NuGet lacks is some kind of smart-updates, it is all-or-nothing >> > about >> > > updates, which keeps this decision messy... >> > > Anyway what I'm saying is: we have to use NuGet-dependency ourselves to >> > make >> > > it work well for our users, too. >> > > Just my 2 inflated-cents, >> > > Rafael "Monoman" Teixeira >> > > --------------------------------------- >> > > "The most exciting phrase to hear in science, the one that heralds new >> > > discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'" >> > > Isaac Asimov >> > > US science fiction novelist & scholar (1920 - 1992) >> >> > > On Tue, Apr 26, 2011 at 8:56 PM, John Simons <[email protected] >> >> > > wrote: >> >> > > The reason we run into this issues is because the project separation is >> > > really only separate VS solutions for each main project. >> >> > > If we go the next step and completely unmarry the projects from each >> > other, >> > > this means not looking at Castle as a package but instead looking at >> > > Windsor, AR, ... on their own, maybe then we do not run into this issue. >> > > But then what is Castle? >> >> > > Maybe the solution is to have combined releases + doco? >> >> > > Cheers, John >> >> > > On 27/04/2011, at 9:27, Henry Conceição <[email protected]> >> > wrote: >> >> > >> It has some pro and cons. >> >> > >> The isolation is good when you think that you're not tied to the other >> > >> projects, specially for releases. But when you try to put all the >> > >> pieces together, it sucks due dll version hell issues. >> >> > >> Cheers, >> > >> Henry Conceição >> >> > >> On Tue, Apr 26, 2011 at 6:37 PM, hammett <[email protected]> wrote: >> > >>> Isn't this a good time to also make an assessment of the project >> > >>> separations? Specifically having all project separated in github. Does >> > >>> it make life harder/easier? >> >> > >>> 2011/4/26 Krzysztof Koźmic <[email protected]>: >> > >>>> That sounds good to me, >> >> > >>>> We'd need to write the "release" scripts pretty much from scratch >> > anyway >> > >>>> so >> > >>>> we might as well do it in RAKE since as you pointed out there's no >> > need >> > >>>> to >> > >>>> have it run elsewhere than on the build server. >> >> > >>>> krzysztof >> >> > >>>> On 26/04/2011 10:49 PM, Roelof Blom wrote: >> >> > >>>> IMHO MSBuild is not really suitable for creating nuget, packaging, >> > >>>> releasing >> > >>>> to SF etc. >> > >>>> As these tasks are only executed by the TeamCity server and/or >> > >>>> committers >> > >>>> rake with Albacore will make this a lot easier and workable. >> > >>>> There are of course ways to get MSBuild to do this (like creating a >> > >>>> nuget >> > >>>> package with NuGet.MSBuild) it's really throwing in more and more XML >> > >>>> for no >> > >>>> apparent benefit. >> > >>>> A combination of "front-end" MSBuild scripts like we have now and a >> > >>>> "back-end" rake script looks best to me. >> > >>>> This way there's no barrier to open and build our projects locally >> > like >> > >>>> they can now, and the rest can just script and automate anything that >> > >>>> comes >> > >>>> to mind with a tool well suited for it. >> > >>>> -- Roelof. >> >> > >>>> 2011/4/25 Krzysztof Koźmic <[email protected]> >> >> > >>>>> I haven't looked beyond putting Nuget package for Windsor 2.5.3 out, >> > >>>>> something that was frequently requested. >> >> > >>>>> I would *love* to have the release process automated (to a point >> > where >> > >>>>> I >> > >>>>> git push to a new tag and our TeamCity recognizes that, and runs a >> > >>>>> release >> > >>>>> build that does everything, including release packaging, releasing to >> > >>>>> SF, >> > >>>>> nuget and OW, branching (if new branch is needed, that is it's not a >> > >>>>> point >> > >>>>> point release and few other things I forgot, like updating the >> > website >> > >>>>> in >> > >>>>> all 3 places.)) >> >> > >>>>> I *strongly* prefer giving MsBuild a fair shot before trying any >> > other >> > >>>>> build solution, mostly because MsBuild is out of the box, it's .NET >> > and >> > >>>>> many >> > >>>>> developers will flat refuse to install Ruby in order to build a .NET >> > >>>>> project. >> >> > >>>>> I think the scripts we have are really well and cleanly written and >> > >>>>> while >> > >>>>> I'm nowhere near as proficient at working with them as Roelof is, >> > I've >> > >>>>> been >> > >>>>> able to tweak them on several occasions, same as I'm sure everyone >> > else >> > >>>>> on >> > >>>>> the team would be. >> >> > >>>>> This however reminds me of another problem I've had, and we'll >> > continue >> > >>>>> having, that is keeping consistency in build scripts among projects. >> > >>>>> I've mostly worked with Core and Windsor and all changes and tweaks >> > >>>>> introduced in one project had to be manually copied to the other one. >> > >>>>> As we >> > >>>>> have many more projects I'm sure trying to deploy changes to build >> > >>>>> process >> > >>>>> all across the board would be nothing short of a nightmare. >> >> > >>>>> Can we please consider some options for automated sharing the build >> > >>>>> files >> > >>>>> among all of our projects so that we only change things once and that >> > >>>>> change >> > >>>>> gets propagated to every project? >> >> > >>>>> I think it might also be beneficial to have a wiki >> >> ... >> >> read more »- 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. > > -- Cheers, hammett http://hammett.castleproject.org/ -- 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. -- 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. -- 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.
