I'm getting ready to release 5.1.17, but I'm having trouble building the
documentation.
I can't even build the documentation using 5.1.16 tag. It worked fine when
I released 5.1.16.Final in August.
A new property was added for HHH-13011, and I need to get that documented
in the user guide for 5.1
Good to know. Thanks!
On Tue, Nov 27, 2018 at 10:15 AM Yoann Rodiere wrote:
> It works the other way: as long as there is a reference to a commit (a
> tag, a branch), the commit stays in the repository. Unreferenced commits
> get garbage-collected.
>
> So you can definitely tag something even i
It works the other way: as long as there is a reference to a commit (a tag,
a branch), the commit stays in the repository. Unreferenced commits get
garbage-collected.
So you can definitely tag something even if you rewrite the corresponding
branch later. The tag will point to a commit that doesn't
One thing that just occurred to me and Jan confirmed on Gitter...
Maintaining those tags will be impossible as long as we have to continue to
re-write history for 6.0 to integrate changes from master - merge is just
not an option there. After each re-write the commits that those tags point
to are
Then Chris and Andrea might as well push it to upstream as soon as they are
done integrating the latest changes from master.
On Tue, Nov 27, 2018 at 9:01 AM Yoann Rodiere wrote:
> Yes, it seems we all agree then. Great :)
>
> About the "labelling" part, yes, that's what I meant.
>
> Yoann Rodièr
Yes, it seems we all agree then. Great :)
About the "labelling" part, yes, that's what I meant.
Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
On Tue, 27 Nov 2018 at 15:52, Steve Ebersole wrote:
> We seem to be "arguing" the same thing. As I said above, I am fine with
> moving it ups
We seem to be "arguing" the same thing. As I said above, I am fine with
moving it upstream. Just making sure everyone has the same expectations
(re-writing, eventual removal, etc) of that upstream branch because they
are not typical of our upstream branches.
I would not really call it "hidden aw
I may be wrong, but I understood your message as an argument that moving
6.0 to upstream would be bad, because having a topic branch upstream is not
a good practice.
Topic branches are typically short-lived and focus on a specific feature or
bugfix. I agree topic branches in upstream would be a me
NP, I could have been more clear.
I guess I see it this way... this is a Work-In-Progress (wip). As such it
has certain implications. In fact I really liked this branch naming
convention (borrowed from Vlad) for just this reason.
On Tue, Nov 27, 2018 at 8:03 AM Davide D'Alto wrote:
> > Well f
> Well first, I never said it would be deleted after the Alpha. I said it
> would be deleted *at some point*, meaning at some point after 6 is moved to
> master.
Sorry, my bad
On Tue, Nov 27, 2018 at 1:34 PM Steve Ebersole wrote:
>
> On Tue, Nov 27, 2018 at 7:22 AM Davide D'Alto wrote:
>>
>>
On Tue, Nov 27, 2018 at 7:22 AM Davide D'Alto wrote:
> +1 for the creation of the branch upstream and everything Yoann said.
>
> One curiosity, once there is an alpha, why would you delete the whole
> branch?
> Couldn't you change everything on the existing branch without deleting it?
> It's unu
+1 for the creation of the branch upstream and everything Yoann said.
One curiosity, once there is an alpha, why would you delete the whole branch?
Couldn't you change everything on the existing branch without deleting it?
It's unusual to rewrite the history of upstream branches but we have
done
+1 to not replace master at this point. At least until the feature coverage
is sufficient and we start to actively fix bugs on 6 and then backport the
fix somehow.
+1 to move wip/6.0 to the main repository with an appropriate warning at
the top of the README.md.
--
Guillaume
On Tue, Nov 27, 201
I'd also be fine with moving to upstream as wip/6.0 with the understanding
that this branch can be re-written and will eventually be deleted.
On Tue, Nov 27, 2018, 1:13 AM Yoann Rodiere wrote:
> I think it would be better to at least move the code to a 6.0 branch on
> the main repository, just
14 matches
Mail list logo
