the jbott logging bot was not around today, so i just captured the
discussion an have attached it here.
Essentially:
1) 4.0.1 release on 4/11
2) after 4.0.1: (a) rename repo; (b) branch 4.0
3) 3.6.10 in 4 weeks (2/8) along with 4.0.2 or 4.1.0
4) intructions on handling repo rename to follow
--
st...@hibernate.org
http://hibernate.org
[08:07] <sebersole> so 4.0.1 tomorrow
[08:07] <sebersole> if you have issues scheduled that you will not get to,
please unschedule them
[08:08] <sebersole> (not push them off, unsxchedule please)
[08:08] <gbadner> can we assign to 4.0.x to keep track of them?
[08:08] <sebersole> no
[08:09] <gbadner> ok
[08:09] <sebersole> we really need to start limiting issues assigned to
ourselves too
[08:09] <gbadner> ok
[08:09] <sebersole> thats i think why we end up with issues scheduled so much
[08:09] <sebersole> i have that problem
[08:10] <sebersole> i have tons of issues assigned to me atm
[08:10] <gbadner> will you have a chance to look at the pull request for
HHH-5472?
[08:10] <jbossbot> jira [HHH-5472] Delay saving an entity if it does not
cascade the save to non-nullable transient entities [Open (Unresolved)
Improvement, Major, Gail Badner] https://hibernate.onjira.com/browse/HHH-5472
[08:10] --> smarlow has joined this channel (~smarlow@redhat/jboss/smarlow).
[08:10] <sebersole> gbadner: if you are interested in an issue, just comment on
it. you get added to the notification list
[08:11] <sebersole> you can also use tags/labels
[08:11] <gbadner> yeah, or I can watch it also
[08:11] <sebersole> gbadner: going to try tonight
[08:12] <sebersole> we also need to decide about possibly doing one more 3.6
releasae
[08:12] <gbadner> yeah, I think it would be a good idea
[08:12] <sebersole> why?
[08:13] <sebersole> gbadner: why do you think its a good idea?
[08:14] <gbadner> just to get some bugfixes backported
[08:15] <gbadner> I could be talked out of it though
[08:15] <sebersole> the reason i ask is because this gets to a larger discussion
[08:15] <gbadner> about branching?
[08:15] <sebersole> cant that same argument be applied to another 3.3 release
gbadner?
[08:16] <sebersole> no about release management
[08:16] <gbadner> no, not 3.3
[08:16] <sebersole> so then there is more to it in your mind than "just to get
some bugfixes backported"
[08:17] <sebersole> like what?
[08:18] <sebersole> for me, the other criteria is because of the major changes
in 4.0
[08:18] <sebersole> but see that is a pro/con as far as an argument
[08:18] <gbadner> maybe just until more people start moving to 4.0.x and
regressions are found
[08:18] <sebersole> essentially a new 3.6 release caters to the people not
wanting to upgrade to 4.0
[08:18] <gbadner> and fix
[08:19] <sebersole> yeah but we *want* people moving to 4.0
[08:19] <gbadner> yes, I agree that it keeps people on 3.6
[08:20] <sebersole> anyway, i think we should do it. one last 3.6 release
[08:20] <sebersole> i think we should do it though with 4.0.2
[08:21] <sebersole> that will give us 4 weeks to identify all fixes we want to
port
[08:21] <gbadner> oh, ok; yeah, that's fine
[08:21] <sebersole> and close out 3.6
[08:22] <gbadner> we're back to a 4-week timebox for 4.0.x, right?
[08:22] <sebersole> or do we just move on to 4.1?
[08:22] <sebersole> gbadner: i think that feels right
[08:23] <sebersole> going back to 4 weeks after the first bugfix release
[08:23] <gbadner> +1
[08:23] <sebersole> we still fine tuning that specific part :)
[08:23] <sebersole> the question is whether we can have 4.1 ready in 4 weeks
[08:24] <sebersole> we dont have to decide that today
[08:25] <sebersole> so i ust added 3.6.10
[08:25] <sebersole> and scheduled for 2/8
[08:25] <gbadner> when do you plan on branching 4.0?
[08:26] <sebersole> tomorrow
[08:26] <sebersole> after i do the release
[08:26] <sebersole> post release will be:
[08:26] <gbadner> oh, ok; sounds good
[08:26] <sebersole> 1) rename the repo hibernate-core -> hibernate-orm
[08:26] <sebersole> 2) branch 4.0
[08:28] <hardy_> probably good idea to create a wiki page on how to handle the
rename if you have your own fork and send out the info on the dev list
[08:28] <sebersole> hardy_: how do you "handle the rename if you have your own
fork"? ;)
[08:29] <sebersole> afair its just dropping your remote and adding a new
[08:29] <stliu> we don't change artifact id, right?
[08:29] <sebersole> stliu: no
[08:29] <hardy_> well, there are two things
[08:30] <hardy_> your local clone and your actual github fork
[08:30] <hardy_> locally you probably get away with changing the remote
[08:30] <hardy_> not sure about the github fork
[08:30] <sebersole> i'll ask on #github
[08:30] <hardy_> you might have to throw it away and fork the new repo
[08:31] <sebersole> and then just repush your work branches?
[08:31] <hardy_> locally you can then of course also update the remote for your
fork
[08:31] <sebersole> (to your fork i mean)
[08:31] <hardy_> yes
[08:31] <sebersole> ok
[08:31] <hardy_> problematic would be if you pushed work to your fork, but
deleted it locally
[08:31] <hardy_> like sandbox experiments
[08:31] <sebersole> just pull it prior i think
[08:31] <hardy_> in this case you have to make sure to pull them again first
[08:32] <hardy_> :-)
[08:32] <sebersole> :D
[08:32] <sebersole> like i said i will ask on #github just to make sure
[08:32] <hardy_> so what I am saying is that we should write a step to step
list of what to do and what to thing about. basically what we just said :-)
[08:32] <hardy_> sweet
[08:32] <sebersole> hardy_: did you see my emails in regards to HHH-5024?
[08:33] <jbossbot> jira [HHH-5024] MetadataContext#registerAttribute does not
recognize inherited fields [Open (Unresolved) Bug, Major, Steve Ebersole]
https://hibernate.onjira.com/browse/HHH-5024
[08:33] <sebersole> could really use some advice there
[08:33] <sebersole> i would like to get that into 4.0.1
[08:33] <sebersole> but if we cant, we cant
[08:33] <sebersole> in the one case there does seem to be an issue with the
generator too
[08:33] <hardy_> I've seen the emails but failed so far to have a closer look
[08:34] <hardy_> i am planning to work on on the generator this or maybe next
week
[08:34] <hardy_> there are several little issues which were piling up
[08:34] <sebersole> hardy_: well i pointed out a test case that illustrates the
issue
[08:34] <sebersole> in the email i mean
[08:35] <sebersole>
hibernate-entitymanager/src/test/java/org/hibernate/ejb/test/metadata/mappedsuperclass/idclass/MappedSuperclassWithEntityWithIdClassTest.java
[08:36] <sebersole> the static metamodel that gets generated for those classes
[08:37] <hardy_> ok
[08:37] <sebersole> those annotations are so confusing imo
[08:38] <sebersole> so then i will probably push this off until after 4.0.1
[08:39] <hardy_> probably best
[08:39] <sebersole> anything else we should cover?
[08:39] <jpav> wrt HHH-6815 (and HHH-6779 that stliu dealt with), I know I've
been sitting on this for quite a while, but I think the customer that
complained about the fix is right. I want to reopen the issue and check in an
"unfix" to this, and just make a simple modification to the test to fix the
ByteTest failure.
[08:39] <gbadner> meeting time
[08:40] <-- jbossbot has left this server (Ping timeout: 240 seconds).
[08:40] <jpav> basically boils down to whose perspective is more important wrt
data semantics, the DB or application
[08:40] <sebersole> jpav: iirc the issues you are talking about...
[08:40] <sebersole> the problem is compatibility
[08:41] <jpav> The customer (and previous releases) assume the application can
"override" the semantics, and for instance allow the app to store a -10 in the
DB even though the column only supports values from 0-255
[08:41] <jpav> yes, between the app and DB
[08:41] <sebersole> no
[08:41] <jpav> I found a way to make an easy change to the test to get it to
work with the old way the code worked
[08:41] <jpav> no to what?
[08:41] <sebersole> between the app running on one version of hibernate and the
app running on another
[08:42] <jpav> no, that's not what I meant
[08:42] --> jbossbot has joined this channel (~jbossbot@redhat/jbossbot).
[08:42] <sebersole> pk
[08:42] <sebersole> well first, lets tralk about jira...
[08:42] <sebersole> we do not reopen closed issues
[08:42] <sebersole> this was something you in particular were adamant about ;)
[08:43] <jpav> Well, it's not closed yet I don't think, just resolved
[08:43] <sebersole> it messes up release notes associated with past releases
[08:43] <sebersole> is it part of a release?
[08:43] <sebersole> thats really the more important criteria
[08:43] <jpav> But , yeah, I get what you mean since its been in a previous
release
[08:44] <sebersole> so you just open a new issue that "follows up on" the old
[08:44] <jpav> sure
[08:44] <sebersole> (thats the link text)
[08:44] <sebersole> k
[08:44] <sebersole> so back to those issues
[08:44] <sebersole> if the new behavior is "more correct" then you make this
switchable
[08:45] <sebersole> but always default to the old behavior
[08:45] <sebersole> although, this happened as part of a major release, so...
[08:46] <hardy_> sebersole: MappedSuperclassWithEntityWithIdClassTest.java -
did you only mention this in an email or does this class exist somewhere in the
source code? I cannot find it
[08:46] <sebersole> i am also ok with making the new behavior the default
(since it is now) and providing an easy switch to the legacy behavior
[08:46] <sebersole> hardy_: ^^ i just gave you the full path
[08:46] <sebersole> [08:35] <sebersole>
hibernate-entitymanager/src/test/java/org/hibernate/ejb/test/metadata/mappedsuperclass/idclass/MappedSuperclassWithEntityWithIdClassTest.java
[08:46] <jpav> okay, I was thinking the same thing. Switchable via some new
property you mean?
[08:46] <hardy_> did you check it in recently?
[08:46] <sebersole> hardy_: yes
[08:46] <hardy_> ahhh
[08:47] <sebersole> jpav: that or an easy swap to the type registry
[08:47] <jpav> k, I'll have to play with the latter to see the affects
[08:48] <gbadner> anyone else seeing infinispan test failures after pulling?
[08:48] <hardy_> sebersole: got it, thanks
[08:48] <sebersole> gbadner: have not tried yet
[08:48] <sebersole> but galder did just upgrade infinispan
[08:48] <hardy_> just building the latest atm
[08:48] <hardy_> can tell you in a few minutes
[08:48] <sebersole> we might really need to move infinispan off somewhere else
[08:48] <stliu> yes, it also fails hudson master job
[08:48] <sebersole> that is getting ridiculous
[08:50] <jpav> that's all I got
[08:50] <gbadner> sebersole, you mentioned we needed to change the meeting time
[08:50] <sebersole> i added a comment to the issue
[08:52] <sebersole> gbadner: its ok, i'll try some other things to work around
it
[08:53] <gbadner> I need to shift back to more day hours, so changing is ok
with me; keeping it the same is ok as well
[08:56] <sebersole> ok, so to wrap up:
[08:57] <sebersole> 1) 4.0.1 tomorrow (4/11)
[08:57] <sebersole> 2) after 4.0.1: (a) rename repo; (b) branch 4.0
[08:58] <sebersole> 3) 3.6.10 in 4 weeks (2/8) along with 4.0.2 or 4.1.0
[08:58] <sebersole> 4) intructions on handling repo rename to follow
[08:58] <sebersole> __EOL__
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
