Started a thread on bf-python about supporting multiple versions of the same addon.
--Nathan On Tue, Feb 26, 2013 at 9:55 AM, Nathan Vegdahl <ces...@cessen.com> wrote: > >> Consider, for example, someone having two different > >> versions of an external renderer installed, and they want to be able > >> to use either/or in different projects (maybe one is more stable, but > >> the other has more features). I think there are meaningful use-cases > >> outside of Rigify and the current situation. > > > > Agree, did you check on adding support for this? > > if you wanted some help investigating ways to implement we could > > continue discussion on bf-python. > > Sounds good. And yeah, I'd be happy to attempt to tackle this after > some discussion. :-) > > >> This is a use-case that should be better supported anyway, IMHO. > > > > Not sure how we would better support this - you can install an addon > > from a zipfile, that parts fairly straightforward. > > I meant better supporting multiple different co-installed versions of > an addon, as per my example of external renderers. > > > Whats inconvenient about maintaining an addon in svn? > > The situation that just came up is a good example: doing contract work > on the addon during pre-release freeze. It puts me in the position of > having to choose between two bad options: committing significant > changes during pre-release freeze, or doing major work without the > safety (and documentation) of incremental commits. Having a separate > development repo (as I'm doing on github now) is a good way around > this, though. > > Also, collaborating with others who are also doing significant > development work on it. Emailing patches back and forth isn't so > nice, and you lose good commit logs that way. DVCS makes this much > nicer. Again, using github or similar for unstable development works > well to resolve this. It's easy for people to branch and share work. > In short, by hosting with DVCS, I get the benefits of DVCS. > > Finally, addons are still very poorly supported in the Blender bug > tracker, with one mega-issue assigned to each. Granted, this is not > related to SVN per se. But I've been annoyed by this for quite some > time, and I'm _very_ keen to skirt around it until it is addressed. > By hosting somewhere else I can point people to the tracker there (in > this case on github) and I then have proper bug/issue/todo tracking > for Rigify. > > > So if you can keep whats in trunk stable, maintained and update fixes > > for release, this works, I just want to avoid fragmentation. > > I don't think that will be a problem. I'll consider the Rigify in SVN > the official supported stable version, and I'll backport bug fixes > etc. > > --Nathan > > > On Mon, Feb 25, 2013 at 2:36 PM, Campbell Barton <ideasma...@gmail.com> > wrote: > > On Tue, Feb 26, 2013 at 8:29 AM, Nathan Vegdahl <ces...@cessen.com> > wrote: > >>> Would prefer addon devs don't do this, some do already but it means we > >>> can't be sure the addon in SVN is really the latest one, have to > >>> contact devs before release to make sure we pull the latest version > >>> in, and it won't be tested as much (or not and have older addons in > >>> which miss features/fixes), > >> > >> While I understand the inconvenience this can pose, there is already > >> too much inconvenience for me the other way around. > > > > Whats inconvenient about maintaining an addon in svn? > > > >> So for the time > >> being, at least, I'm going to do primary development of Rigify on > >> github (http://github.com/cessen/rigify), and merge stable changes > >> during the appropriate BCon stages. If the development model for > >> addons included with Blender changes at some point, I'll reconsider. > >> But I don't think that model necessarily needs to change. > > > > Don't blame you, I've been using git for development too (then moving > > into svn when ready). > > > > So if you can keep whats in trunk stable, maintained and update fixes > > for release, this works, I just want to avoid fragmentation. > > > >> I treat (and want to treat) Rigify as an independent project, and > >> would really prefer a less centralized development model for it, and > >> inclusion as an officially supported addon hinders both those things > >> by design. So this seems like a decent compromise: it lets me develop > >> it independently as needed/wanted, but it can still be included as an > >> official addon for those who want it to be so. We can think of the > >> github repo as something like a development branch. > > > > Ok, as a dev branch I see where your coming from, I still worry a bit > > that changes wont be tested as well in our development builds. > > > >> I would also be perfectly happy for Rigify to not be included as an > >> official addon, but I think there may be others that would object to > >> that. For example, there was a certain someone that argued in favor > >> of its inclusion after Sintel. ;-) > > > > It's a shame if we can't provide users good tools by default (even > > though they need to be enabled). > > If rigify is fairly small and kept working with current blender > > releases, I don't see why not include it. > > > >>> users who want to test latest version need > >>> to manually grab it. - just becomes a hassle IMHO, ...makes conflicts > >>> more likely too. > >> > >> This is a use-case that should be better supported anyway, IMHO. > > > > Not sure how we would better support this - you can install an addon > > from a zipfile, that parts fairly straightforward. > > The hassle is mostly that users need to know what to search for in the > > first place, trust the script isn't malicious, check the version > > matches their blender and manually update it from the authors web > > site. > > > >> Obviously if two conflicting versions of an addon are enabled > >> simultaneously, we can't expect that to work. But simply having two > >> different versions of an addon present... not sure why that needs be > >> an issue. > > > > Not sure what your getting at here, it shouldn't be an issue, I'm > > quite sure it can be added. > > > >> Consider, for example, someone having two different > >> versions of an external renderer installed, and they want to be able > >> to use either/or in different projects (maybe one is more stable, but > >> the other has more features). I think there are meaningful use-cases > >> outside of Rigify and the current situation. > > > > Agree, did you check on adding support for this? > > if you wanted some help investigating ways to implement we could > > continue discussion on bf-python. > > > >> --Nathan > > > > -- > > - Campbell > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers