-
Notifications
You must be signed in to change notification settings - Fork 686
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update NHibernate and net framework #386
Conversation
<tags>ORM DAL NHibernate DataBase ADO.Net Mappings Conventions</tags> | ||
<copyright>Copyright (c) James Gregory and contributors (Paul Batum, Hudson Akridge, Gleb Chermennov, Jorge Rodríguez Galán).</copyright> | ||
<dependencies> | ||
<dependency id="NHibernate" version="5.0.3" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be better to use this this syntax [5.0.3, 6.0)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tend to think that it is better to use the idea of resilient builds. We should always know what version we are using. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that would affect builds since the specific version of NHibernate will be specified in the projects packages.config anyway. I think it will only affect the version that is initially installed into a project the first time someone adds FluentNHibernate.
I am not sure if specifying the upper limit on the NHibernate version is a good idea or not as we don't know if version 6.0 will break any functionality with fluent.
src/CommonAssemblyInfo.cs
Outdated
[assembly: AssemblyVersion("1.1.0.0")] | ||
[assembly: AssemblyFileVersion("1.1.0.0")] | ||
[assembly: AssemblyInformationalVersion("1.1.0")] | ||
[assembly: AssemblyCopyright("Copyright 2008-2017 James Gregory and contributors (Paul Batum, Hudson Akridge, Gleb Chermennov, Jorge Rodríguez Galán). All rights reserved.")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change to 2008-2018
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I'll wait a bit for someone else to pronounce with code reviews and then I'll fix what's necessary. Thank you
</ProjectReference> | ||
|
||
<ItemGroup> | ||
<PackageReference Include="EntityFramework" Version="6.2.0" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need a reference to EntityFramework?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not at the beginning. So I think we can safely remove the dependency from tests and example projects. 👍
@@ -15,7 +15,7 @@ public class when_there_is_any_unpaired_collection_property_alphabetically_befor | |||
CollectionMapping collectionWithoutBackrefAndAlphabeticallyFirst; | |||
CollectionMapping collectionWithoutBackrefAndAlphabeticallyLast; | |||
CollectionMapping collectionWithCorrespondingBackref; | |||
ManyToOneMapping referenceFromChildSecondTypeToParent; | |||
// ManyToOneMapping referenceFromChildSecondTypeToParent; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me
*@jrgcubano* TeamCity configuration needs to be updated accordingly, if
we decide to continue using it going forward
2018-01-12 13:04 GMT+03:00 Andreas Eriksson <notifications@github.com>:
… ***@***.**** commented on this pull request.
------------------------------
In nuspec/FluentNHibernate.nuspec
<#386 (comment)>
:
> + <metadata xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
+ <id>FluentNHibernate</id>
+ <title>FluentNHibernate</title>
+ <version>0.0.0</version>
+ <description>Fluent, XML-less, compile safe, automated, convention-based mappings for NHibernate.</description>
+ <summary>Fluent, XML-less, compile safe, automated, convention-based mappings for NHibernate.</summary>
+ <authors>James Gregory and contributors (Paul Batum, Hudson Akridge, Gleb Chermennov, Jorge Rodríguez Galán).</authors>
+ <owners>jagregory, chester89, jagregory</owners>
+ <licenseUrl>https://github.com/jagregory/fluent-nhibernate/raw/master/LICENSE</licenseUrl>
+ <projectUrl>https://github.com/jagregory/fluent-nhibernate</projectUrl>
+ <iconUrl>https://raw.githubusercontent.com/jagregory/fluent-nhibernate/master/docs/logo-nuget.png</iconUrl>
+ <requireLicenseAcceptance>false</requireLicenseAcceptance>
+ <tags>ORM DAL NHibernate DataBase ADO.Net Mappings Conventions</tags>
+ <copyright>Copyright (c) James Gregory and contributors (Paul Batum, Hudson Akridge, Gleb Chermennov, Jorge Rodríguez Galán).</copyright>
+ <dependencies>
+ <dependency id="NHibernate" version="5.0.3" />
I don't think that would affect builds since the specific version of
NHibernate will be specified in the projects packages.config anyway. I
think it will only affect the version that is initially installed into a
project the first time someone adds FluentNHibernate.
I am not sure if specifying the upper limit on the NHibernate version is a
good idea or not as we don't know if version 6.0 will break any
functionality with fluent.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#386 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AALnfOw4eNEjVVyTbmQ4s6ErCM1tnq-Pks5tJy4XgaJpZM4RYRxK>
.
--
Yours faithfully,
Gleb
|
I'm on the same boat as you @jrgcubano, it would be ashame to let this project die. I've been using Fluent nhibernate for about 10 years now and i'm really looking forward to seeing this update being released. Please push on :-) If you need more hands on deck @chester89 i'm ready to help in every way i can. With support for .net core 2.0 coming in nhibernate 5.1 (if all works about), these will become very interesting times ! Especially if we get fluent flowing with it .... |
We are having some problems with continuous integration. We are working on it. |
FluentNHibernate is back Finally we shipped the new version. We moved the repo to a github organization (FluentNHibernate). We are planing new changes to be in sync with the next version of NHibernate and NetCore. https://www.nuget.org/packages/FluentNHibernate Sorry for the delay! |
Implements #385
References #383 #365 #381
First of all,
Thank you all the contributors for maintaining this project for so many years. It has been amaizing to be able to use it. 👍
I needed too urgently to use the project with the the lastest NHibernate, so I have updated the project to the lastest version of NHibernate and projects to the new world of .net.
I think I speak for many when saying that the project should not die. I am open to sharing the project administration and help with its updates from now on if necessary. You can give me access to the repo and I can configure the required steps to integrate this PR.
I have tried everything with an "Unofficial" fork version of the whole process (Cake, AppVeyor, Nuget, etc) in my account. jrgcubano fluent-nhibernate github
General updates:
Projects:
NHibernate:
Tests and Specs
Build system:
** Note: When NHibernate upgrade the project to NetStandard and NetCore, it will be a matter of small changes to update the projects and the build pipeline.
In case the PR be well received and can be taken into account to accept it. We need some steps to follow and enviroment vars to be defined on appveyor by the repo owner and minor badges changes.
AppVeyor steps:
Pending:
@jagregory @chester89 Please, let me know what you think about all these changes.
Thanks.