I mentioned it just because since they invented it, then they might have had some good ideas of how to employ it. In fact, although they don't change assembly versions, they change file versions for core assemblies with patches and SPs. For example, although System.dll has assembly version 2.0.0.0, on my machine running Vista SP2 the file version is 2.0.50727.4016, which is probably different on a different OS: http://en.wikipedia.org/wiki/.NET_Framework_version_list
On Feb 13, 11:33 pm, John Simons <[email protected]> wrote: > @Simone, Does it really matter what MS does? > > On Feb 13, 11:35 pm, SimoneB <[email protected]> wrote: > > > > > Is this how MS versions core assemblies like System.dll though .net fx > > releases? > > > On Feb 13, 7:38 am, John Simons <[email protected]> wrote: > > > > There has been a few threads about people not being able to easily > > > (without having to recompile the whole thing) swap assemblies with the > > > latest > > > ones.http://groups.google.com/group/castle-project-devel/browse_thread/thr... > > > > Jono, proposed the following: > > > "So maybe the alternative is to not increment the assembly version but > > > the > > > file version for hotfix/patch releases (i.e. 2.0.1, 2.0.2). Which > > > means that > > > you could just drop in a patch release without worrying about updating > > > dependant libraries, this then ensures the user is using compatible > > > versions > > > and allows us to fix bugs that don't break public interfaces." > > > > Which I think is a good idea. +1 > > > > What does everyone else think about this? > > > > Cheers > > > John -- 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.
