Hi all,
I've implemented some "facilities" in master branch that you may want to know
about... It's not yet documented (will be, when I'll have time).
The hack is quite simple: just add a config/local_define.php file in your tree.
In this file, you can define GLPI_DEMO_MODE or
Hello,
9.1.3 release is planned at the end of the week.
Code is now freezed, no more commits will reach the 9.1/bugfixes branch until
release has been done.
This will permit to finalize tests and prepare the release.
Have a good day!
Regards,
--
Johan
Hello,
We plan to release GLPI 9.1.2 on 2017-01-23.
We can continue to fix some bugs, we will freeze the whole process on
1027-01-17 or 2017-01-18 (to keep some time to do some checks and prepare the
release).
After this date, no more fixes will be merged until release has been tagged (or
Hello all,
As I've previously talked about; I began to write a developer doc, stored on a
github repository, and published on readthedocs.
I'll tell you a bit more about my choices regarding this.
I've decided to use reStructuredText instead of markdown syntax (but not
lateX). Why?
Just
Hello,
> I think we also need a "Release Manager" ;)
>
> - create the branch
> - tag the version
> - create / publish the tarball
> - check which commits can go in the branch after a RC.
I'm pretty OK with that.
> And perhaps we also need a "9.1.1" branch
>
> So only "critical" remaining bugs
Hello Yllen,
> For plugin i had made de doc for name convention and describe a creation
> step by step.
> It's in french and in 0.84 but it's the same for 9.1
> https://forge.glpi-project.org/projects/plugins/wiki/Fr_CreatePlugin084
Really great, I'll complete/fix what I wrote from your
Hello Yllen,
> I have made some change for array and block doc of function
Great, thank you very much :)
I've fixed a small issue in the "code-block" calls ;)
--
Johan
___
Glpi-dev mailing list
Glpi-dev@gna.org
(As far as I can see, I sent this mail 2 days ago but it has not been
delivered... Excuse me if you receive this twice)
Hello all,
Some time ago, we've talked here about some workflow and rules for the
development of the project.
I wrote some lines and put all online. You can see the latest
Hello,
> https://github.com/glpi-project/docdev/issues/1
Agree :)
> - Improve the DBmysqlIterator
>
> https://github.com/glpi-project/glpi/pull/1096
>
> - suport COUNT(*)
I had in mind that count(*) is not the best choie for performances reasons. Am
I wrong?
> Other goal: add
Hello,
Thanks for you comments :)
> > It's me introduce this version number because in old versions of
> > GLPI, a plugin is only compatible with a major version of GLPI. Since
> > 0.85, plugins are compatible 0.85 & 0.90.
> >
> > For example, I have plugins compatible 0.85/0.90 not compatible
Hello all,
I was thinking about plugins versions and compatibility... And that sounds like
a nightmare to me :)
I have questions, and maybe some ideas, here it is.
First, some plugins versions contains a GLPi version (like 0.90-1.0); what is
the inital goal of that? This version of the plugin
Hello,
> A fix cause less problem in PR, the only things will be the test
> (enough test or not).
>
> But an urgent bug fix not mean a release in urgency, so it can be
> opened some hours (not some days :p)
Agree but anyways, bugfix or not, "urgent" or not ; if the PR is OK and has
been
Hello,
> For PR adding a feature / changing a behavior, I think we need to keep
> it open before merging for some time (1 day ?) so other developpers can
> comment it (e.g. https://github.com/glpi-project/glpi/pull/945)
OK for me, let's say PR will stay opened one day.
++
--
Johan
Hello,
- Mail original -
> De: "David DURIEUX"
> À: "Liste de diffusion des developpeurs GLPI"
> Envoyé: Mercredi 7 Septembre 2016 11:16:46
> Objet: [Glpi-dev] Modify coding methods to enhance code quality
>
> Hello,
>
> I propose new coding
14 matches
Mail list logo